dialog gui challenge - mega modal markup oddities

[scottaohara]

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. The menu element is another type of list element - specifically referenced in the spec as being similar to ul. As such, it expects li 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 than div > 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 of menu > buttons, it probably makes more sense to just turn these into divs as well.

Snippet of the rendered markup I grabbed using dev tools:

<footer>
  <menu>
    <button type="reset" value="clear">Clear</button>
  </menu>
  <menu>
    <button autofocus="" type="button" onclick="this.closest('dialog').close('cancel')">Cancel</button>
    <button type="submit" value="confirm">Confirm</button>
  </menu>
</footer>

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.

[argyleink]

very interesting information! thank you for takin the time to detail it out. there's learning for me all over this logged issue 👍🏻