frend / frend.co

Frend — A collection of accessible, modern front-end components.

Home Page:http://frend.co

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Generate Dialog Modal on demand? (modal bugs)

goetsu opened this issue · comments

Hi,

to conform to the aria design pattern the dialog need to have an aria-label or aria-labelledby instead of aria-describedby and the focus must be moved to the first focusable item inside the dialog (the close button) not on the dialog itself.

It also better to generate the dialog on demand when open and then removing it from the DOM when close at the end of the source code this way you can hide the rest of the page with an aria-hidden="true" when the dialog is open and removing it when close. It's especially usefull when you are in mobile to prevent touch outside of the modale

Thanks @goetsu, I'll get a fix in for the aria-labelledby and initial focus.

I'm interested in your thoughts about generating the dialog on demand, we strive to progressively enhance our components wherever we can so ideally we don't want to rely on JS to render the component. Obviously that will remove the modal capabilities of the component but it will still be available as another section of the document to navigate to. Do you see any issues with the content being available/rendered in the document without the modal functionality?

+1 on label

Won't disagree with focusing within modal, but WAI also says "If there is no focusable item in the dialog, focus is placed on the dialog container element."

I don't see any issue with progressively enhancing. This is how I do it in my example: http://bit.ly/1Rn8OgJ

Thanks for your input @goetsu & @weboverhauls, I've implemented the following fixes in #81

  • aria-labelledby is now in place instead of aria-describedby
  • focus is now applied to first item in the modal (but will focus the container if no focusable elements exist) as per the spec

I'm still interested in whether there are any issues progressively enhancing the modal itself, I don't see how rendering the content on the page without JS would present any problems. We can let the user decide whether they want to show or hide it.

Worth coming back to the point regarding the aria-hidden on the main element when the dialog is open. We could build this in without too much trouble, and add some advice in the markup example/documentation.

Interesting read by Rob Dodson on how modals are susceptible to "ghost controls" when using aria-hidden alone. What are everyone's thoughts on this?

I wouldn't worry about it. You're doing all the best practices and the modal is very accessible.

Closing this for now, perhaps the aria-hidden on main issue could be opened as a separate issue, it definitely needs more research.