E-mail List Archives
Thread: Multiple *accessible* ways
Number of posts in this thread: 3 (In chronological order)
From: wolfgang.berndorfer
Date: Fri, Mar 27 2020 9:14AM
Subject: Multiple *accessible* ways
No previous message | Next message →
SC 2.4.5 requires more than one way to get to a subside. But:
a) Has every way to be accessible according to *this SC*?
b) Does this SC require at least *two accessible ways*?
Let's think of a website with a nav that isn't keyboard accessible. A
violation of SC 2.1.1. But the sitemap and the search functionalities are
accessible.
Thanks for clarification and opinions.
Wolfgang
From: glen walker
Date: Fri, Mar 27 2020 12:02PM
Subject: Re: Multiple *accessible* ways
← Previous message | Next message →
That's a thought provoking question. Even though the SC doesn't say the
"way" must be accessible, perhaps it's implied.
Think about 2.4.1 Bypass Blocks. If I have good html semantics, then as a
screen reader user, I could navigate by headings or landmarks to bypass
blocks of common content. So 2.4.1 would satisfy *my* needs and the
"mechanism" to bypass is using semantic html screen reader shortcut keys.
However, if using headings and landmarks were the *only* way to bypass
blocks of content, then I (as an accessibility evaluator) would fail that
SC because it doesn't help a keyboard user. 2.4.1 doesn't say the
"mechanism" must be accessible but isn't that the whole point of each SC?
But that's my personal interpretation. It doesn't mean it's correct.
But to relate that to your 2.4.5 example, if 2.4.1 used semantic html, so a
screen reader can easily bypass blocks of content and I had a skip link
that was accessible, then that would pass 2.4.1. But if I had a third way
to bypass content that was *not* accessible to everyone, would that then
cause 2.4.1 to fail? I think that's the gist you're getting at. For
2.4.5, you're saying you have two accessible ways to get to pages but you
also have a third way that is not accessible, does that cause 2.4.5 to fail?
I think it would pass 2.4.5 and would be a 2.1.1 failure, as you
suggested. In my 2.4.1 example, 2.4.1 would pass (because there was an
accessible way to bypass content) but my third inaccessible way to bypass
content would fail some other SC.
I had to run your example through my head several times. I didn't get what
you were asking initially until I started typing, then it hit me what you
were asking. But I had already typed all this and didn't want to waste my
keystrokes :-)
On Fri, Mar 27, 2020 at 9:14 AM < = EMAIL ADDRESS REMOVED = > wrote:
> SC 2.4.5 requires more than one way to get to a subside. But:
>
> a) Has every way to be accessible according to *this SC*?
>
> b) Does this SC require at least *two accessible ways*?
>
>
>
> Let's think of a website with a nav that isn't keyboard accessible. A
> violation of SC 2.1.1. But the sitemap and the search functionalities are
> accessible.
>
>
>
> Thanks for clarification and opinions.
>
> Wolfgang
>
> > > > >
From: wolfgang.berndorfer
Date: Fri, Mar 27 2020 4:25PM
Subject: Re: Multiple *accessible* ways
← Previous message | No next message
Sorry for my poor English: each / every. Of course, it should mean:
a) Has *each* way to be accessible according to *this SC*?
Hope, this helps understanding my question.
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > Im Auftrag von glen
walker
Gesendet: Freitag, 27. März 2020 19:03
An: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Betreff: Re: [WebAIM] Multiple *accessible* ways
That's a thought provoking question. Even though the SC doesn't say the
"way" must be accessible, perhaps it's implied.
Think about 2.4.1 Bypass Blocks. If I have good html semantics, then as a
screen reader user, I could navigate by headings or landmarks to bypass
blocks of common content. So 2.4.1 would satisfy *my* needs and the
"mechanism" to bypass is using semantic html screen reader shortcut keys.
However, if using headings and landmarks were the *only* way to bypass
blocks of content, then I (as an accessibility evaluator) would fail that SC
because it doesn't help a keyboard user. 2.4.1 doesn't say the "mechanism"
must be accessible but isn't that the whole point of each SC?
But that's my personal interpretation. It doesn't mean it's correct.
But to relate that to your 2.4.5 example, if 2.4.1 used semantic html, so a
screen reader can easily bypass blocks of content and I had a skip link that
was accessible, then that would pass 2.4.1. But if I had a third way to
bypass content that was *not* accessible to everyone, would that then cause
2.4.1 to fail? I think that's the gist you're getting at. For 2.4.5,
you're saying you have two accessible ways to get to pages but you also have
a third way that is not accessible, does that cause 2.4.5 to fail?
I think it would pass 2.4.5 and would be a 2.1.1 failure, as you suggested.
In my 2.4.1 example, 2.4.1 would pass (because there was an accessible way
to bypass content) but my third inaccessible way to bypass content would
fail some other SC.
I had to run your example through my head several times. I didn't get what
you were asking initially until I started typing, then it hit me what you
were asking. But I had already typed all this and didn't want to waste my
keystrokes :-)
On Fri, Mar 27, 2020 at 9:14 AM < = EMAIL ADDRESS REMOVED = > wrote:
> SC 2.4.5 requires more than one way to get to a subside. But:
>
> a) Has every way to be accessible according to *this SC*?
>
> b) Does this SC require at least *two accessible ways*?
>
>
>
> Let's think of a website with a nav that isn't keyboard accessible. A
> violation of SC 2.1.1. But the sitemap and the search functionalities
> are accessible.
>
>
>
> Thanks for clarification and opinions.
>
> Wolfgang
>
> > > archives at http://webaim.org/discussion/archives
> >
http://webaim.org/discussion/archives