The second group of Sufficient Techniques for 2.4.1 - Bypass Blocks involves grouping blocks of repeated material with ARIA, headings, frames, etc. None of these techniques seem to help keyboard-only/magnification users, who still may have to move through a bunch of navigation links. Am I missing something here?

The idea behind landmarks was (and is) the hope that browser vendors
will take advantage of them, and implement shortcut mechanisms for
keyboard only users.
As for 2.4.1 as it related to keyboard only users, I usually look more
at accessible mega menus, accordions, tabs/tabpnels and other complex
widgets that reduce the amount of key presses necessary to get to the
desired content on a web page.

E.g. if your site boasts a navigation megamenu that consists of 4 or 5
main menu links, each with 8 to 10 item submenus, it is important to
enable keyboard navigation pattern that enables the user to utilize
the arrow keys to quickly navigate within the menu rather than only
implementing shortcuts for mouse users but leave the keyboard only
user to fend for him or herself, armed with nothing but the tabkey.

Let me ask another way. A webpage has a left navigation menu of 20 items, or top navigation of 5 items. A keyboard-only user has to tab through these on every page within the site, but the main content has a landmark or h1 tag. Technically this seems to meet 2.4.1, but would seem to violate the spirit of the guideline until browsers can use landmarks. Do I give the site a pass for 2.4.1, but note the usability issue? If the developer is required to meet WCAG 2.0 and this is a pass, is there another guideline I can use to get them to add a skip link?

The idea behind landmarks was (and is) the hope that browser vendors will take advantage of them, and implement shortcut mechanisms for keyboard only users.
As for 2.4.1 as it related to keyboard only users, I usually look more at accessible mega menus, accordions, tabs/tabpnels and other complex widgets that reduce the amount of key presses necessary to get to the desired content on a web page.

E.g. if your site boasts a navigation megamenu that consists of 4 or 5 main menu links, each with 8 to 10 item submenus, it is important to enable keyboard navigation pattern that enables the user to utilize the arrow keys to quickly navigate within the menu rather than only implementing shortcuts for mouse users but leave the keyboard only user to fend for him or herself, armed with nothing but the tabkey.

I would make the lack of a skip link as a strong recommendation under
WCAG SC 2.4.1.
I would describe it along the lines of:
"Though implementing a heading and landmark structure is technically
sufficient to meet this success criterion, and it does for users of
assistive technology apps such as screen readers, the lack of browser
support for keyboard navigation to landmarks creats a major usability
issue for people who rely on keyboard only or keyboard simulators).
for possible additional background or remediation suggestions I would
normally point them tohttp://terrillthompson.com/blog/161
(except there is no need for the JQuery backup solution, it is
sufficient to put tabindex="-1" on target).
anticipating a large user base with outdated browsers and assistive
technologies).
I have never seen anyone actually implementing the skip to widget
developed by PayPal
https://github.com/paypal/skipto
but it is an interesting aproach.
I cannot call this as a violation of any other WCAG SC, 2.1.1 only
states that all functionality on page is operable via keyboard only,
2.2.2 requires no keyboard traps.
There is nothing about excessive tabbing in WCAG SC except for 2.4.1.
They could post links to browser add-ons that enable keyboard
navigation to landmarks, but that is probably not the greatest
solution.
Going forward We, as a community, need to keep pushing on browser
vendors to do their bit and implement some sort of keyboard shortcuts
to landmarks, at least to the main landmark.
Thank

On 7/15/15, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> Let me ask another way. A webpage has a left navigation menu of 20 items, or
> top navigation of 5 items. A keyboard-only user has to tab through these on
> every page within the site, but the main content has a landmark or h1 tag.
> Technically this seems to meet 2.4.1, but would seem to violate the spirit
> of the guideline until browsers can use landmarks. Do I give the site a pass
> for 2.4.1, but note the usability issue? If the developer is required to
> meet WCAG 2.0 and this is a pass, is there another guideline I can use to
> get them to add a skip link?
>
> Thanks.
>
> Joseph
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Tuesday, July 14, 2015 4:57 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Bypass Blocks for Keyboard users
>
> The idea behind landmarks was (and is) the hope that browser vendors will
> take advantage of them, and implement shortcut mechanisms for keyboard only
> users.
> As for 2.4.1 as it related to keyboard only users, I usually look more at
> accessible mega menus, accordions, tabs/tabpnels and other complex widgets
> that reduce the amount of key presses necessary to get to the desired
> content on a web page.
>
> E.g. if your site boasts a navigation megamenu that consists of 4 or 5 main
> menu links, each with 8 to 10 item submenus, it is important to enable
> keyboard navigation pattern that enables the user to utilize the arrow keys
> to quickly navigate within the menu rather than only implementing shortcuts
> for mouse users but leave the keyboard only user to fend for him or herself,
> armed with nothing but the tabkey.
>
>
>
> On 7/14/15, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>> The second group of Sufficient Techniques for 2.4.1 - Bypass Blocks
>> involves grouping blocks of repeated material with ARIA, headings,
>> frames, etc. None of these techniques seem to help
>> keyboard-only/magnification users, who still may have to move through
>> a bunch of navigation links. Am I missing something here?
>>
>> Joseph
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > >

I realize this is very controversial, but I still lean toward calling a 2.4.1 violation if a skip link isn't present. My reasoning is that while the techniques don't specifically address keyboard users, I feel it's not in the spirit of WCAG to call for a mechanism that can't be used by the user base most highly impacted. Sure browsers could and should add keyboard support for landmark/heading navigation, but until that's a reality, we have real users with real barriers with no real solution other than to say that the "mechanism" actually should be considered to be functionality and hence available to keyboard users.

Let me ask another way. A webpage has a left navigation menu of 20 items, or top navigation of 5 items. A keyboard-only user has to tab through these on every page within the site, but the main content has a landmark or h1 tag. Technically this seems to meet 2.4.1, but would seem to violate the spirit of the guideline until browsers can use landmarks. Do I give the site a pass for 2.4.1, but note the usability issue? If the developer is required to meet WCAG 2.0 and this is a pass, is there another guideline I can use to get them to add a skip link?

The idea behind landmarks was (and is) the hope that browser vendors will take advantage of them, and implement shortcut mechanisms for keyboard only users.
As for 2.4.1 as it related to keyboard only users, I usually look more at accessible mega menus, accordions, tabs/tabpnels and other complex widgets that reduce the amount of key presses necessary to get to the desired content on a web page.

E.g. if your site boasts a navigation megamenu that consists of 4 or 5 main menu links, each with 8 to 10 item submenus, it is important to enable keyboard navigation pattern that enables the user to utilize the arrow keys to quickly navigate within the menu rather than only implementing shortcuts for mouse users but leave the keyboard only user to fend for him or herself, armed with nothing but the tabkey.

Oh donÂ´t get me wrong.
I would cite with Steve in a heartbeat if push came to a shove.
Fortunately the recommendation alone, with a practical demo if
necessary, is usually enough to make developers see the light, hear
the sound, smell the stink .. whatever you want to call it.

On 7/15/15, Steve Sawczyn < = EMAIL ADDRESS REMOVED = > wrote:
> I realize this is very controversial, but I still lean toward calling a
> 2.4.1 violation if a skip link isn't present. My reasoning is that while
> the techniques don't specifically address keyboard users, I feel it's not in
> the spirit of WCAG to call for a mechanism that can't be used by the user
> base most highly impacted. Sure browsers could and should add keyboard
> support for landmark/heading navigation, but until that's a reality, we have
> real users with real barriers with no real solution other than to say that
> the "mechanism" actually should be considered to be functionality and hence
> available to keyboard users.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Joseph Sherman
> Sent: Wednesday, July 15, 2015 9:00 AM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] Bypass Blocks for Keyboard users
>
> Let me ask another way. A webpage has a left navigation menu of 20 items, or
> top navigation of 5 items. A keyboard-only user has to tab through these on
> every page within the site, but the main content has a landmark or h1 tag.
> Technically this seems to meet 2.4.1, but would seem to violate the spirit
> of the guideline until browsers can use landmarks. Do I give the site a pass
> for 2.4.1, but note the usability issue? If the developer is required to
> meet WCAG 2.0 and this is a pass, is there another guideline I can use to
> get them to add a skip link?
>
> Thanks.
>
> Joseph
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Tuesday, July 14, 2015 4:57 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Bypass Blocks for Keyboard users
>
> The idea behind landmarks was (and is) the hope that browser vendors will
> take advantage of them, and implement shortcut mechanisms for keyboard only
> users.
> As for 2.4.1 as it related to keyboard only users, I usually look more at
> accessible mega menus, accordions, tabs/tabpnels and other complex widgets
> that reduce the amount of key presses necessary to get to the desired
> content on a web page.
>
> E.g. if your site boasts a navigation megamenu that consists of 4 or 5 main
> menu links, each with 8 to 10 item submenus, it is important to enable
> keyboard navigation pattern that enables the user to utilize the arrow keys
> to quickly navigate within the menu rather than only implementing shortcuts
> for mouse users but leave the keyboard only user to fend for him or herself,
> armed with nothing but the tabkey.
>
>
>
> On 7/14/15, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>> The second group of Sufficient Techniques for 2.4.1 - Bypass Blocks
>> involves grouping blocks of repeated material with ARIA, headings,
>> frames, etc. None of these techniques seem to help
>> keyboard-only/magnification users, who still may have to move through
>> a bunch of navigation links. Am I missing something here?
>>
>> Joseph
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > >
> > > > >

Is this the correct way to add a comment to a thread? An email to this
address? - if not please let me know how to do it as I can't see any link
for the purpose. My comment is as follows:

Joseph, if I am reading your posts correctly, you are having a problem
persuading your company to add a Skip link because they don't see that WCAG
requires them to do it. So why not fall back on disability discrimination
law? In the US the Americans with Disabilities Act, and in the UK the
Equality Act 2010 (and similar legislation in most countries) prohibit
discrimination. Period. Of any kind.

On that basis, if somone produces a website where sighted users can click
menus easily, and screen reader users can get quick access, but the web
designers effectively say to keyboard users, "Sorry you are going to have
to click every one of these 30+ links on every page of our site you visit.
We could solve the problem easily with a Skip link but we aren't going to
because fundamentally we don't give tuppence for you, we are far more
concerned about our own [WCAG] rules as we perceive them, so go take a
hike", then that's discrimination by anyones standards!

Users could use the above laws to mount a law suit over this, regardless of
what the WCAG says or doesn't say, and the opposition would lose the case.
That should surely move your people!

I am very much in favor of having browsers implement landmark navigation
for keyboard-only users, but in one-on-one conversations with some of the
people who actually write code for the browsers, there is some deep-seated
resistance to doing that, even among accessibility advocates and blind
programmers at these companies. I really don't get it. They're attitude is
that it should be an add-on and not a core feature of the browser. I
disagree completely, but nothing is going to change until we change the
minds of the people who are creating the browsers, who currently don't like
the idea.

Paul Bohman wrote:
> there is some deep-seated resistance to doing that, even among
> accessibility advocates and blind programmers at these companies.
> I really don't get it.

Likewise. Perhaps we could gain support by not presenting it as only
an accessibility solution. I don't have a motor disability, but would
LOVE to have the ability to navigate through landmarks natively in my
browser. It would be amazing to hit M to jump to the main content, S
to search, N to cycle through navigation elements, etc.

I've been saying for many years that the most significant thing that
could happen right now that would have the biggest immediate impact on
end user accessibility would be for common browsers to support heading
and landmark/region keyboard navigation. And once supported, "skip"
links could go away - and good riddance to them.

There is, in general, deep-seated resistance at browser manufacturers against implementing most accessibility support as native options: access to ARIA, native implementation of MathML, even the ability to view alt without knowing how to access an individual image's properties. The convinction that this should all be exposed via assistive tech or in browser extensions is incompatible with the known fact that most people with mild AT needs will never install assistive tech or any kind of browser add-on, and will never know there's the ability to navigate a website in a manner browsers don't expose.

Deborah Kaplan

On Fri, 17 Jul 2015, Paul Bohman wrote:

> I am very much in favor of having browsers implement landmark navigation
> for keyboard-only users, but in one-on-one conversations with some of the
> people who actually write code for the browsers, there is some deep-seated
> resistance to doing that, even among accessibility advocates and blind
> programmers at these companies. I really don't get it. They're attitude is
> that it should be an add-on and not a core feature of the browser. I
> disagree completely, but nothing is going to change until we change the
> minds of the people who are creating the browsers, who currently don't like
> the idea.
>
>
> Paul Bohman, PhD
> Director of Training, Deque Systems, Inc
> https://DequeUniversity.com
> 703-225-0380, ext.121

Maybe an alternative solution would be to create a plugin, one that could
be added into the browsers as a toolbar. It would simply list the landmark
regions, and the user could either tab to it and along it, or press a
hotkey which would be assigned to each region (M for Main etc) as they
preferred.

There is, in general, deep-seated resistance at browser manufacturers against implementing most accessibility support as native options: access to ARIA, native implementation of MathML, even the ability to view alt without knowing how to access an individual image's properties. The convinction that this should all be exposed via assistive tech or in browser extensions is incompatible with the known fact that most people with mild AT needs will never install assistive tech or any kind of browser add-on, and will never know there's the ability to navigate a website in a manner browsers don't expose.

Deborah Kaplan

On Fri, 17 Jul 2015, Paul Bohman wrote:

> I am very much in favor of having browsers implement landmark
> navigation for keyboard-only users, but in one-on-one conversations
> with some of the people who actually write code for the browsers,
> there is some deep-seated resistance to doing that, even among
> accessibility advocates and blind programmers at these companies. I
> really don't get it. They're attitude is that it should be an add-on
> and not a core feature of the browser. I disagree completely, but
> nothing is going to change until we change the minds of the people who
> are creating the browsers, who currently don't like the idea.
>
>
> Paul Bohman, PhD
> Director of Training, Deque Systems, Inc https://DequeUniversity.com
> 703-225-0380, ext.121

Especially given how many user agent manufacturers participate very actively on the other working groups.

Deborah

On Sat, 18 Jul 2015, Jonathan Avila wrote:

>> There is, in general, deep-seated resistance at browser manufacturers against implementing most accessibility support as native options:
>
> I think this is evidenced by the lack of participation in groups such as the User Agent Accessibility Guidelines Working Group.
> http://www.w3.org/WAI/UA/wai-ua-members.html
>
> Jonathan
>

Yes, an alternative to built-in browser keyboard page navigation support
would be a plugin, and there in fact a few basic plugins that do that. The
problem with that mindset, though, is that it concedes that accessibility
support is an optional enhancement. Most people will never know that the
add-on exists. They won't install it, and web developers will have to
continue putting in "skip navigation" hacks on their designs.

Real traction can be achieved only when accessibility goes mainstream.

> Maybe an alternative solution would be to create a plugin, one that could
> be added into the browsers as a toolbar. It would simply list the landmark
> regions, and the user could either tab to it and along it, or press a
> hotkey which would be assigned to each region (M for Main etc) as they
> preferred.
>
> Guy Hickling
> > > > >

> Maybe an alternative solution would be to create a plugin, one that could
> be added into the browsers as a toolbar. It would simply list the landmark
> regions, and the user could either tab to it and along it, or press a
> hotkey which would be assigned to each region (M for Main etc) as they
> preferred.
>
> Guy Hickling
> > > > >

Yes, the link that Steve provided to the Firefox bug about landmark
navigation is particularly insightful. Note that it dates all the way back
to 2011 and still no action has been taken. Somewhat recently I added my
own plea at the bottom of that list:
https://bugzilla.mozilla.org/show_bug.cgi?idg0928#c55

I encourage people to up-vote that bug and add their own comments to help
get the attention of Firefox developers!

On Fri, Jul 17, 2015 at 11:14:20AM -0600, Jared Smith wrote:
> Likewise. Perhaps we could gain support by not presenting it as only
> an accessibility solution. I don't have a motor disability, but would
> LOVE to have the ability to navigate through landmarks natively in my
> browser. It would be amazing to hit M to jump to the main content, S
> to search, N to cycle through navigation elements, etc.

But that's exactly why they think it should be an add-on. Look at
current add-ons: stuff a few people want because they personally
like it. That some (including me) would LOVE to be able to navigate
like we could in Presto is, to vendors, little different from those
who LOVE to surf the web while blocking ads, or having rainbow
browser chrome, or having some testing tools.

How do we convince them that this is more like ARIA, MathML etc
and belong to (growing larger all the time) cores?