WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?

for

From: Birkir R. Gunnarsson
Date: Aug 11, 2020 9:48AM

Keep in mind that lack of keyboard accessiblity (2.1.1) is essentialy
a critical fail, so that alone should be enough to elevate the element
to the top of the remediation list.
Steve gave a great overview of how this could relate to 1.3.1, any
state (expanded/collapsed), function (an image indicating that the
trigger element has a dropdown functionality) needs a corresponding
programmatic or text equivalent.



On 8/11/20, Steve Green < <EMAIL REMOVED> > wrote:
> Our usual interpretation of 1.3.1 is that if a series of links looks like it
> is a navigation item, it should be marked-up in a <nav> element with a
> unique "aria-label" attribute that describes its purpose, such as "main
> menu", "secondary navigation", "breadcrumb" etc.
>
> Furthermore, if the series of links look like a list (which they invariably
> do) they should be marked-up as a <ul> element.
>
> Dropdown menus usually look like nested lists, so that is how they should be
> marked-up.
>
> The visually expanded / collapsed state of the dropdowns need to be conveyed
> programmatically using the "aria-expanded" attribute.
>
> Depending on how the menu is constructed, there may be other visual aspects
> that need to be conveyed programmatically.
>
> If all these things are done, the structure of the menu and the relationship
> between the top-level link and the sub-links in the pull-down menu will
> survive when the menu is being accessed by a screen reader.
>
> Without seeing the code I can't say which WCAG success criteria your menu
> doesn't conform with. However, if the menu is not keyboard accessible, it is
> likely that other success criteria are non-conformant. It may or may not be
> conformant with 1.3.1.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
>