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: Steve Green
Date: Aug 11, 2020 8:42AM

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


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Jim Byrne Accessible Web Design
Sent: 11 August 2020 15:07
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [WebAIM] Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?

Hi,

Just wondering what your thoughts are on this:

Re: Understanding Success Criterion 1.3.1: Info and Relationships

This success criteria is about ensuring that, 'information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.'

So would a drop-down menu that is inaccessible to screen readers (and keyboards users) mean this checkpoint fails?

There's no indication that the checkpoint is designed to include this kind of issue, as it refers to tables, colour, forms with required fields - and the robustness of these - to different presentation.

Clearly the structure of the menu and the relationship between the the top-level link and the sub-links in the pull-down menu does not survive - when the menu is being access by a screen reader. So it should be a fail?

Any thoughts?

Sorry if I'm missing something here.

Thanks,
Jim