AW: AW: "Bypass Blocks" Question

Hi Deborah, All

You have absolutely right with saying that the best and only correct keyboard navigation solution lays in the hand of browser implementors. But we live "now", not in the future. And all main browser developing organizations are members of W3C and know from the beginning about accessibility issues including the currently discussed one.
When I recommended "jump links" it was a traditional answer, a still interim solution, but unfortunately, as you said, plug-ins and extensions are no solution and never will be. So the only way to conform to WCAG 2.0 in this point currently is still the interim solution way ugly, unbeloved jump links.
I hope the browser developer will soon make the situation better - they know about the need for years.
Mario Batusic
Accessibility at www.fabasoft.com

> -----Ursprüngliche Nachricht-----
> Von: deborah.kaplan@suberic.net [mailto:deborah.kaplan@suberic.net]
> Gesendet: Montag, 20. Juli 2015 19:09
> An: Phill Jenkins
> Cc: Web Accessibility Initiative Interest Group
> Betreff: Re: AW: "Bypass Blocks" Question
> 
> On Mon, 20 Jul 2015, Phill Jenkins wrote:
> > 1. It would be better to educate end users on how to install and use
> > the plug-ins available,
> 
> This is simply impractical. Most users outside of technology don't use plug-
> ins/extensions, don't know they exist, don't know how to search for them, and
> don't know how to decide which ones are safe or useful for them. This is unlikely
> to change.
> 
> The most quickly growing pool of people with accessibility needs will always
> include people who are elderly, which is unlikely to be a pool of people who will
> necessarily be excited about searching for and installing plug-ins and extensions.
> A huge number of people with disabilities live in poverty, and these are not
> necessarily people who have the resources to make it reasonable to prioritize
> searching for browser extensions.
> 
> The browsers should supply basic accessibility. This is not unreasonable. You
> should not need add-ons and extensions to get accessibility.
> 
> > So the problem seems to be "us", the accessibility community, for not
> > posting resources about the various capabilities in the browsers,
> > plug-in, and extensions, including JavaScript frameworks for keyboard
> > navigation for end-users.  Below is an initial resource list.  Please
> > copy, add-to, and post to increase the community awareness.  We are never
> going to make the progress we need to by asking the millions of web sites to add
> skip nav links when a relatively very few browsers and open source community
> folks can solve the problem for us.  Asking web site owners to go beyond using
> the structural mark-up and adding skip nav links too, that we have been asking
> for for over a decade, is not working.  Lets all try to be more efficient in our
> recommendations by using all the guidelines we have, including UAAG .
> 
> We, the accessibility community, are never going to be reaching every person
> with an accessibility need. It's not going to happen. It's not that we aren't trying
> hard enough, and it's not that we don't have the resources -- it is that we cannot
> do it.
> 
> You are right that asking site owners to add skip nav links is not working. Nor
> should they need to. If they write in semantically correct HTML 5, with ARIA
> markup where appropriate, there is absolutely no reason that the user agents
> couldn't create the keyboard skip navigation from that markup. We should not
> be asking site owners to work around what are effectively browser bugs; we
> should demand fixes in the browsers. We should not be relying on add-ons and
> extensions that most users will never discover; we should demand fixes in the
> browsers. As you say, with your point 2:
> 
> 
> > 2. It would be more efficient to request more capabilities from the
> > developers / manufacturers of the relatively very few browsers.
> 
> A small number of browsers are the most efficient way to fix the problem.
> 
> Deborah Kaplan

Received on Tuesday, 21 July 2015 06:01:20 UTC