E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Jim Byrne Accessible Web Design
Date: Tue, Aug 11 2020 8:07AM
Subject: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?
No previous message | Next message →

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

From: Steve Green
Date: Tue, Aug 11 2020 8:42AM
Subject: Re: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Tue, Aug 11 2020 9:48AM
Subject: Re: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?
← Previous message | Next message →

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 ADDRESS 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
>
>
>

From: Patrick H. Lauke
Date: Tue, Aug 11 2020 10:27AM
Subject: Re: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?
← Previous message | Next message →

1.3.1 is one of those that, if you look hard enough, can potentially
apply to a lot of different types of failures. I think in most cases (in
my experience at least) auditors use 1.3.1 mostly to fail
structure/relationship, but not things like conveying state (and leave
that for 4.1.2, assuming we're talking about interactive controls/widgets).

The fact that something *is* a dropdown, and whether it's expanded or
collapsed, I'd usually put under 4.1.2. The actual structure of the
dropdown itself, if incorrect, I'd pop under 1.3.1.

(And of course, the keyboard aspect is 2.1.1)

There's often a bit of overlap in these interpretations, and depends on
how "must fail this under all the relevant SCs" you are when
auditing/reporting. Comes down to consistency in reporting, more than
anything else, I'd say.

P

On 11/08/2020 15:07, Jim Byrne Accessible Web Design wrote:
> 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
>
>
>
>
> > > > >

--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Laura Fathauer
Date: Wed, Aug 12 2020 1:28PM
Subject: Re: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?
← Previous message | Next message →

There is also the issue of where the submenu is located; if the
submenu is placed elsewhere in the page away from the activating
element, i.e. after the footer/at the end of the page, then 1.3.2
Meaningful sequence may be implicated.

Laura

On Tue, Aug 11, 2020 at 12:27 PM Patrick H. Lauke
< = EMAIL ADDRESS REMOVED = > wrote:
>
> 1.3.1 is one of those that, if you look hard enough, can potentially
> apply to a lot of different types of failures. I think in most cases (in
> my experience at least) auditors use 1.3.1 mostly to fail
> structure/relationship, but not things like conveying state (and leave
> that for 4.1.2, assuming we're talking about interactive controls/widgets).
>
> The fact that something *is* a dropdown, and whether it's expanded or
> collapsed, I'd usually put under 4.1.2. The actual structure of the
> dropdown itself, if incorrect, I'd pop under 1.3.1.
>
> (And of course, the keyboard aspect is 2.1.1)
>
> There's often a bit of overlap in these interpretations, and depends on
> how "must fail this under all the relevant SCs" you are when
> auditing/reporting. Comes down to consistency in reporting, more than
> anything else, I'd say.
>
> P
>
> On 11/08/2020 15:07, Jim Byrne Accessible Web Design wrote:
> > 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
> >
> >
> >
> >
> > > > > > > > > >
>
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Jim Byrne Accessible Web Design
Date: Thu, Aug 13 2020 4:23AM
Subject: Re: Success Criterion 1.3.1: Info and Relationships: what about inaccessible drop-down menus?
← Previous message | No next message

Thanks Steve, et al,

None of the elements or attributes you mention are used, so although the checkpoint does not appear to be principally design to indicate the type of failure that I have outlined (because this failure is caught by other checkpoints) - it does fail when matched against a literal reading of the checkpoint description. However, as others have pointed out, a lots of things would fail this checkpoint if it was taken so literally.

However it fails when tested against your explanation below.

Thanks,
Jim

> On 11 Aug 2020, at 15:42, Steve Green < = EMAIL ADDRESS 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
>
>
>