generated from argyleink/shortstack
-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dialog gui challenge - mega modal markup oddities #205
Comments
very interesting information! thank you for takin the time to detail it out. there's learning for me all over this logged issue 👍🏻 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
regarding: https://web.dev/building-a-dialog-component/
it's mentioned that the footer, header and article elements are semantic containers - but there's little explanation as to why they're there, or the impact they'll have for people using screen readers.
In reality, these don't serve much purpose in the context of the dialog - header/footer should generally be treated as generic in these cases - though not consistently. So these may also be exposed as banner/contentinfo landmarks, which adds verbosity with little gain. Similar to the article element which will be exposed as an unnamed article container, which at worse requires someone have to perform additional navigational steps to reach the inner content (for instance, if using VO navigation keys). At best, similar to the header/footer elements, just adds extra verbosity to this dialog.
Similarly, the use of the
menu
element invalid here. Themenu
element is another type of list element - specifically referenced in the spec as being similar toul
. As such, it expectsli
elements as its direct children, but you've just put buttons in there. This is "fine" for the most part, in that some browsers/AT mitigate against this error by not exposing the list semantics and thus treating this no differently thandiv > button
. But not NVDA, as one example, where when used with Chrome/Edge it informs me that i've entered a list, but as there are no list items i can't navigate by them. Since it doesn't appear that you want to visually expose this as a list - particularly since the rendered demo even uses two separate instances ofmenu > button
s, it probably makes more sense to just turn these into divs as well.Snippet of the rendered markup I grabbed using dev tools:
If you did want this to be exposed as a list, seems reasonable to have a single menu, and then li's containing the 3 buttons. That too may be a bit more chatty than someone actually needs, but it'd be valid markup then and not have inconsistent exposure to AT.
The text was updated successfully, but these errors were encountered: