E-mail List Archives

Search E-mail List Archives for

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

From: Jennison Asuncion
Date: Tue, Sep 10 2013 9:53PM
Subject: for Chrome devs: intro to accessibility course
No previous message | Next message →

Hi,

This free, online course from Google's Accessibility team is targeted at devs and others who work using Chrome. While the course is called Introduction to Web Accessibility, the specific focus is on blind/visually impaired users' accessibility.

Jennison


Jennison Mark Asuncion
Co-Director, Adaptech Research Network http://www.adaptech.org
LinkedIn at http://www.linkedin.com/in/jennison
Follow me on Twitter http://www.twitter.com/jennison
Accessibility Camp Toronto http://www.youtube.com/watch?v=XeP5Kl4GDgA
From: Jennison Mark Asuncion [ = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, September 10, 2013 11:43 PM
To: Jennison Asuncion
Subject: Fwd: Introduction to Web Accessibility online course

---------- Forwarded message ----------
From: Eve Andersson < = EMAIL ADDRESS REMOVED = >
Date: Tue, 10 Sep 2013 10:56:32 -0700 (PDT)
Subject: Introduction to Web Accessibility online course
To: = EMAIL ADDRESS REMOVED =

Hi everyone,

Today we announced<http://googledevelopers.blogspot.com/2013/09/make-your-website-more-accessible-to.html>;registration
for Introduction to Web Accessibility, our online course that
helps you discover simple ways to make your websites more accessible to
visually impaired users, without breaking code or sacrificing a beautiful
user experience.* * This course is intended for software developers, and it
teaches the basics of ARIA markup and tools and techniques for accessible
development. The course runs with support from Google content experts
from September
17-30 (but the content will remain available after the course officially
ends).

To learn more about the course, check out our GDL
episode<https://developers.google.com/live/shows/919837902>featuring
members of our accessibility team (myself included) in
conversation with Vint Cerf, Google’s VP & Chief Internet Evangelist.

If you or any web developers you know would find this course useful, visit
g.co/webaccessibility to register.

Thanks!

Eve Andersson
Manager, Accessibility Engineering
Google

From: Alastair Campbell
Date: Wed, Sep 11 2013 3:42AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Jennison Asuncion wrote:

> This free, online course from Google's Accessibility team is targeted at
> devs and others who work using Chrome. While the course is called
> Introduction to Web Accessibility, the specific focus is on blind/visually
> impaired users' accessibility. g.co/webaccessibility


Is anyone else uncomfortable with how user-agent specific the course
appears to be?

It isn't just that it appears to reinforce the view that accessibility visual impairment, but also that ChromeVox appears to be the primary tool
for testing.

It is especially troubling given Marco's excellent explanation of why
ChromeVox can interpret things differently, as it doesn't use the browser's
API:
http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/

I'm almost inclined to tell developers and even accessibility testers *not*
to use ChromeVox as it the least used, and it is likely to work differently
from the ones that people do use.

I'll hold criticism for the moment as the course materials are not up yet,
but alarm bells are ringing...

-Alastair

From: Olaf Drümmer
Date: Wed, Sep 11 2013 4:29AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

My concern is the focus on "visual impairment + screen reader". This runs the risk of severely limiting the much needed increase of awareness among web developers. Tailoring a web site only to visually impaired users using screen readers can actually decrease the accessibility for others.

From my point of view, at least one other mode of accessing content (beyond screen readers) **must** be explained (and forced upon people taking such a course).

It would already be helpful to work with another variation of visual impairment - low vision. A typical type of AT here are substantial magnification of content and text customisation (where the default layout of the web page is left behind). By using such AT different types of issues can be unearthed.

Regarding Chrome Vox: it has the huge advantage that it readily just works in a widely used browser on at least Mac and Windows. Yeah, its different from other screen readers. Yeah, strictly speaking it is not even a real screen reader, as once outside Chrome you are on your own again. But: once installed, a web developer can activate/inactivate any time with a keyboard short cut. It has visual highlighting, which takes it beyond NVDA. It is not as clumsy as VoiceOver on Mac OS X (which is a pain if you turn it on and off a couple of times). All ion all I would say Chrome Vox is just fine for use by web developers trying to find issues.

So - main complaint from my side: at least one other type of AT (than screen reader) should be included (there are various readily available options for that! - for example, I find that NoSquint for FireFox is of extreme educational value for me).


But let's not kill an initiative like this course - it's still better than nothing. Though it could probably be much more than what it seems to be today without too much additional effort...


Olaf


Am 11 Sep 2013 um 11:42 schrieb Alastair Campbell < = EMAIL ADDRESS REMOVED = >:

> Jennison Asuncion wrote:
>
>> This free, online course from Google's Accessibility team is targeted at
>> devs and others who work using Chrome. While the course is called
>> Introduction to Web Accessibility, the specific focus is on blind/visually
>> impaired users' accessibility. g.co/webaccessibility
>
>
> Is anyone else uncomfortable with how user-agent specific the course
> appears to be?
>
> It isn't just that it appears to reinforce the view that accessibility > visual impairment, but also that ChromeVox appears to be the primary tool
> for testing.
>
> It is especially troubling given Marco's excellent explanation of why
> ChromeVox can interpret things differently, as it doesn't use the browser's
> API:
> http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
>
> I'm almost inclined to tell developers and even accessibility testers *not*
> to use ChromeVox as it the least used, and it is likely to work differently
> from the ones that people do use.
>
> I'll hold criticism for the moment as the course materials are not up yet,
> but alarm bells are ringing...
>
> -Alastair
> > >

From: Jennison Asuncion
Date: Wed, Sep 11 2013 5:07AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

I have nothing to do with the course myself, but keep in mind that it is being run by Google, so it makes sense that they would want to promote and encourage use of their tool suite. I also know that lots of devs are Chrome users, so making these folks aware of what is available to them (as a start) for testing development for accessibility using Chrome is better than nothing. I definitely agree that this would not represent thorough accessibility work, but it's a piece of it.

Re the focus on blindness and visual impairment, lets hope Google launches other courses. For now, they've got this one up.

Jennison


Jennison Mark Asuncion
Co-Director, Adaptech Research Network http://www.adaptech.org
LinkedIn at http://www.linkedin.com/in/jennison
Follow me on Twitter http://www.twitter.com/jennison
Accessibility Camp Toronto http://www.youtube.com/watch?v=XeP5Kl4GDgA

From: Cameron Cundiff
Date: Wed, Sep 11 2013 6:14AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

On Wed, Sep 11, 2013 at 5:42 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> Jennison Asuncion wrote:
>
> > This free, online course from Google's Accessibility team is targeted at
> > devs and others who work using Chrome. While the course is called
> > Introduction to Web Accessibility, the specific focus is on
> blind/visually
> > impaired users' accessibility. g.co/webaccessibility
>
>
> Is anyone else uncomfortable with how user-agent specific the course
> appears to be?
>
>
It seems more practical to focus on a single user agent and screen reader
for a course of limited scope. Chrome is integral to the dev environment of
many web development professionals I know, mostly because it is fast and
has excellent build in debugging tools.


> It isn't just that it appears to reinforce the view that accessibility > visual impairment, but also that ChromeVox appears to be the primary tool
> for testing.
>

ChromeVox seems like the natural option when using the Chrome browser and
given the scope of the course (and that it's Google). Even though VoiceOver
works well with Chrome, it is a black box with regards to its API as far as
I can tell, so less useful in terms of outlining the technology. NVDA is
Windows only. This is my personal experience again, but most web devs I
know use a Mac.


> It is especially troubling given Marco's excellent explanation of why
> ChromeVox can interpret things differently, as it doesn't use the browser's
> API:
> http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
>

I agree with Marco (see my follow up comment and link on the post). I'd
like to see VoiceOver be the de facto testing tool for devs on OS X. But
its still has roadblocks for dev workflow without patching.


> I'm almost inclined to tell developers and even accessibility testers *not*
> to use ChromeVox as it the least used, and it is likely to work differently
> from the ones that people do use.
>

This is a great point, though I'd ask, is ChromeVox high enough fidelity
that it would be useful? Is it so different that it'd be harmful, and in
what ways?

I'll hold criticism for the moment as the course materials are not up yet,
> but alarm bells are ringing...
>
> -Alastair
> > > >

From: Alastair Campbell
Date: Wed, Sep 11 2013 8:31AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Cameron Cundiff wrote:

> is ChromeVox high enough fidelity
> that it would be useful? Is it so different that it'd be harmful, and in
> what ways?


I wish I knew! I don't have much experience with ChromeVox, so I'm working
from other people's comments, but scenario that worries me is:

A developer creates an interface and tests it on ChromeVox. It seems to
work fine, so they move on.

As Bryan commented on Marco's post:
http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/#li-comment-617540
In the new(ish) WAI-ARIA stuff you can code to standards and still create
something unusable to the *people* using it. Even if ChromeVox were 100%
correct and to standard, that would still be a problem because the others
are not, or even just interpret it differently.

When working with developers the process I recommend for "as you go along"
testing by the developer is can you complete the user-tasks:
1. With just the keyboard?
2. When you zoom in (or increase text size, depending on the CSS layout) to
200% and still use/understand it?
3. With a common screen reader (generally NVDA on Windows, VoiceOver on OSX
or iOS).

Obviously the QA/accessibility people have a longer list of things to
check, but I use that ordering with developers to emphasize keyboard-only
and visual aspects, before they get stuck into screen readers.

I am in severe danger of pre-judging Google's course, but given the number
of developers who use Chrome extensively, Google are in a position of great
influence.

-Alastair

From: Cameron Cundiff
Date: Wed, Sep 11 2013 8:37AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

I think it'd be useful to have a comparison between ChromeVox and
VoiceOver. I hope to have a post on the Pivotal Labs blog soon. I'll share
it here when it's finished.

On Wed, Sep 11, 2013 at 10:31 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >wrote:

> Cameron Cundiff wrote:
>
> > is ChromeVox high enough fidelity
> > that it would be useful? Is it so different that it'd be harmful, and in
> > what ways?
>
>
> I wish I knew! I don't have much experience with ChromeVox, so I'm working
> from other people's comments, but scenario that worries me is:
>
> A developer creates an interface and tests it on ChromeVox. It seems to
> work fine, so they move on.
>
> As Bryan commented on Marco's post:
>
> http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/#li-comment-617540
> In the new(ish) WAI-ARIA stuff you can code to standards and still create
> something unusable to the *people* using it. Even if ChromeVox were 100%
> correct and to standard, that would still be a problem because the others
> are not, or even just interpret it differently.
>
> When working with developers the process I recommend for "as you go along"
> testing by the developer is can you complete the user-tasks:
> 1. With just the keyboard?
> 2. When you zoom in (or increase text size, depending on the CSS layout) to
> 200% and still use/understand it?
> 3. With a common screen reader (generally NVDA on Windows, VoiceOver on OSX
> or iOS).
>
> Obviously the QA/accessibility people have a longer list of things to
> check, but I use that ordering with developers to emphasize keyboard-only
> and visual aspects, before they get stuck into screen readers.
>
> I am in severe danger of pre-judging Google's course, but given the number
> of developers who use Chrome extensively, Google are in a position of great
> influence.
>
> -Alastair
> > > >

From: Steve Faulkner
Date: Wed, Sep 11 2013 8:52AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Hi cameron,

it is a black box with regards to its API as far as
>


The mapping of ARIA attributes to Mac OSX accessibility API is available
http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table (last
column)

for HTML
http://www.w3.org/TR/html-aapi/#html-element-to-accessibility-api-role-mapping-matrix

It should be noted that VoiceOver uses the accessibility API information
exposed by the browser exclusively for web content. It does not interpret
the DOM directly.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 11 September 2013 13:14, Cameron Cundiff < = EMAIL ADDRESS REMOVED = > wrote:

> On Wed, Sep 11, 2013 at 5:42 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Jennison Asuncion wrote:
> >
> > > This free, online course from Google's Accessibility team is targeted
> at
> > > devs and others who work using Chrome. While the course is called
> > > Introduction to Web Accessibility, the specific focus is on
> > blind/visually
> > > impaired users' accessibility. g.co/webaccessibility
> >
> >
> > Is anyone else uncomfortable with how user-agent specific the course
> > appears to be?
> >
> >
> It seems more practical to focus on a single user agent and screen reader
> for a course of limited scope. Chrome is integral to the dev environment of
> many web development professionals I know, mostly because it is fast and
> has excellent build in debugging tools.
>
>
> > It isn't just that it appears to reinforce the view that accessibility > > visual impairment, but also that ChromeVox appears to be the primary tool
> > for testing.
> >
>
> ChromeVox seems like the natural option when using the Chrome browser and
> given the scope of the course (and that it's Google). Even though VoiceOver
> works well with Chrome, it is a black box with regards to its API as far as
> I can tell, so less useful in terms of outlining the technology. NVDA is
> Windows only. This is my personal experience again, but most web devs I
> know use a Mac.
>
>
> > It is especially troubling given Marco's excellent explanation of why
> > ChromeVox can interpret things differently, as it doesn't use the
> browser's
> > API:
> > http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
> >
>
> I agree with Marco (see my follow up comment and link on the post). I'd
> like to see VoiceOver be the de facto testing tool for devs on OS X. But
> its still has roadblocks for dev workflow without patching.
>
>
> > I'm almost inclined to tell developers and even accessibility testers
> *not*
> > to use ChromeVox as it the least used, and it is likely to work
> differently
> > from the ones that people do use.
> >
>
> This is a great point, though I'd ask, is ChromeVox high enough fidelity
> that it would be useful? Is it so different that it'd be harmful, and in
> what ways?
>
> I'll hold criticism for the moment as the course materials are not up yet,
> > but alarm bells are ringing...
> >
> > -Alastair
> > > > > > > >
> > > >

From: Alastair Campbell
Date: Wed, Sep 11 2013 9:00AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Cameron wrote:
> it is a black box with regards to its API

There is an accessibility inspector that's part of Xcode, if you are on the
OSX development programme thingy. I assume that would show you the
attributes in the tables Steve mentioned.

-Alastair

From: Birkir R. Gunnarsson
Date: Wed, Sep 11 2013 9:09AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Just remember that Chrome Vox use, as reported by the latest WebAIM
screen reader survey, was less then .5%, Voiceover around 12%, NVDA
around 14% and Jaws still in the 50% range.
As long as screen readers and standards play nice (and there is
consistency regarding the interpretation and support of standards)
this should not matter too much, but when screen reading applications
support standards partially, or come up with their own set of rules
and best practices, people need to at least be aware of the fact that
if they test with a screen reader with very small userbase and that
has its own take on how to most accessibly acquire and communicate
info, this could lead to a lot of frustration and inconsistencies in
how the developer experiences problems and how the users do. So from
that perspective, NVDA would be a lot more useful than Chrome Vox
(this is just a general statement, I have not tried using Chrome Vox
myself, it is on my ever-lengthening to-do list).
I am curious to see what the Google accessibility course will be like
and, moreover, if the course is accessible to a screen reader user (it
better be, else that would be embarrassing for them to say the least).
Cheers
-Birkir
Birkir Gunnarsson
Accessibility Subject Matter Expert | Deque Systems




On 9/11/13, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
> Cameron wrote:
>> it is a black box with regards to its API
>
> There is an accessibility inspector that's part of Xcode, if you are on the
> OSX development programme thingy. I assume that would show you the
> attributes in the tables Steve mentioned.
>
> -Alastair
> > > >

From: Cameron Cundiff
Date: Wed, Sep 11 2013 9:17AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Thank you Steve, I am excited to have this resource, and I'll review it
carefully.


On Wed, Sep 11, 2013 at 10:52 AM, Steve Faulkner
< = EMAIL ADDRESS REMOVED = >wrote:

> Hi cameron,
>
> it is a black box with regards to its API as far as
> >
>
>
> The mapping of ARIA attributes to Mac OSX accessibility API is available
> http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table (last
> column)
>
> for HTML
>
> http://www.w3.org/TR/html-aapi/#html-element-to-accessibility-api-role-mapping-matrix
>
> It should be noted that VoiceOver uses the accessibility API information
> exposed by the browser exclusively for web content. It does not interpret
> the DOM directly.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>
>
> On 11 September 2013 13:14, Cameron Cundiff < = EMAIL ADDRESS REMOVED = > wrote:
>
> > On Wed, Sep 11, 2013 at 5:42 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> > > Jennison Asuncion wrote:
> > >
> > > > This free, online course from Google's Accessibility team is targeted
> > at
> > > > devs and others who work using Chrome. While the course is called
> > > > Introduction to Web Accessibility, the specific focus is on
> > > blind/visually
> > > > impaired users' accessibility. g.co/webaccessibility
> > >
> > >
> > > Is anyone else uncomfortable with how user-agent specific the course
> > > appears to be?
> > >
> > >
> > It seems more practical to focus on a single user agent and screen reader
> > for a course of limited scope. Chrome is integral to the dev environment
> of
> > many web development professionals I know, mostly because it is fast and
> > has excellent build in debugging tools.
> >
> >
> > > It isn't just that it appears to reinforce the view that accessibility
> > > > visual impairment, but also that ChromeVox appears to be the primary
> tool
> > > for testing.
> > >
> >
> > ChromeVox seems like the natural option when using the Chrome browser and
> > given the scope of the course (and that it's Google). Even though
> VoiceOver
> > works well with Chrome, it is a black box with regards to its API as far
> as
> > I can tell, so less useful in terms of outlining the technology. NVDA is
> > Windows only. This is my personal experience again, but most web devs I
> > know use a Mac.
> >
> >
> > > It is especially troubling given Marco's excellent explanation of why
> > > ChromeVox can interpret things differently, as it doesn't use the
> > browser's
> > > API:
> > > http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
> > >
> >
> > I agree with Marco (see my follow up comment and link on the post). I'd
> > like to see VoiceOver be the de facto testing tool for devs on OS X. But
> > its still has roadblocks for dev workflow without patching.
> >
> >
> > > I'm almost inclined to tell developers and even accessibility testers
> > *not*
> > > to use ChromeVox as it the least used, and it is likely to work
> > differently
> > > from the ones that people do use.
> > >
> >
> > This is a great point, though I'd ask, is ChromeVox high enough fidelity
> > that it would be useful? Is it so different that it'd be harmful, and in
> > what ways?
> >
> > I'll hold criticism for the moment as the course materials are not up
> yet,
> > > but alarm bells are ringing...
> > >
> > > -Alastair
> > > > > > > > > > > >
> > > > > > > >
> > > >

From: Cameron Cundiff
Date: Wed, Sep 11 2013 9:24AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Alistair, I assume this is what you are describing: Testing for
Accessibility on OS
X<https://developer.apple.com/library/mac/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTesting/OSXAXTestingApps.html>.
I'll investigate. Thanks!

On Wed, Sep 11, 2013 at 11:00 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >wrote:

> Cameron wrote:
> > it is a black box with regards to its API
>
> There is an accessibility inspector that's part of Xcode, if you are on the
> OSX development programme thingy. I assume that would show you the
> attributes in the tables Steve mentioned.
>
> -Alastair
> > > >

From: Steve Faulkner
Date: Wed, Sep 11 2013 9:27AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Hi Cameron, this may also be helpful:

http://www.html5accessibility.com/

it's not been updated for a year now (i am getting to it) but it provides
an overview of the various browser acc implementations.

Note: since Opera now uses the blink rendering engine its support pretty
much tracks chrome.

also useful for ARIA and when to use roles to add support for elements
semantics: http://rawgithub.com/w3c/aria-in-html/master/index.html

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 11 September 2013 16:17, Cameron Cundiff < = EMAIL ADDRESS REMOVED = > wrote:

> Thank you Steve, I am excited to have this resource, and I'll review it
> carefully.
>
>
> On Wed, Sep 11, 2013 at 10:52 AM, Steve Faulkner
> < = EMAIL ADDRESS REMOVED = >wrote:
>
> > Hi cameron,
> >
> > it is a black box with regards to its API as far as
> > >
> >
> >
> > The mapping of ARIA attributes to Mac OSX accessibility API is available
> > http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table (last
> > column)
> >
> > for HTML
> >
> >
> http://www.w3.org/TR/html-aapi/#html-element-to-accessibility-api-role-mapping-matrix
> >
> > It should be noted that VoiceOver uses the accessibility API information
> > exposed by the browser exclusively for web content. It does not interpret
> > the DOM directly.
> >
> > --
> >
> > Regards
> >
> > SteveF
> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> >
> >
> > On 11 September 2013 13:14, Cameron Cundiff < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > On Wed, Sep 11, 2013 at 5:42 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >
> > > wrote:
> > >
> > > > Jennison Asuncion wrote:
> > > >
> > > > > This free, online course from Google's Accessibility team is
> targeted
> > > at
> > > > > devs and others who work using Chrome. While the course is called
> > > > > Introduction to Web Accessibility, the specific focus is on
> > > > blind/visually
> > > > > impaired users' accessibility. g.co/webaccessibility
> > > >
> > > >
> > > > Is anyone else uncomfortable with how user-agent specific the course
> > > > appears to be?
> > > >
> > > >
> > > It seems more practical to focus on a single user agent and screen
> reader
> > > for a course of limited scope. Chrome is integral to the dev
> environment
> > of
> > > many web development professionals I know, mostly because it is fast
> and
> > > has excellent build in debugging tools.
> > >
> > >
> > > > It isn't just that it appears to reinforce the view that
> accessibility
> > > > > > visual impairment, but also that ChromeVox appears to be the primary
> > tool
> > > > for testing.
> > > >
> > >
> > > ChromeVox seems like the natural option when using the Chrome browser
> and
> > > given the scope of the course (and that it's Google). Even though
> > VoiceOver
> > > works well with Chrome, it is a black box with regards to its API as
> far
> > as
> > > I can tell, so less useful in terms of outlining the technology. NVDA
> is
> > > Windows only. This is my personal experience again, but most web devs I
> > > know use a Mac.
> > >
> > >
> > > > It is especially troubling given Marco's excellent explanation of why
> > > > ChromeVox can interpret things differently, as it doesn't use the
> > > browser's
> > > > API:
> > > > http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
> > > >
> > >
> > > I agree with Marco (see my follow up comment and link on the post). I'd
> > > like to see VoiceOver be the de facto testing tool for devs on OS X.
> But
> > > its still has roadblocks for dev workflow without patching.
> > >
> > >
> > > > I'm almost inclined to tell developers and even accessibility testers
> > > *not*
> > > > to use ChromeVox as it the least used, and it is likely to work
> > > differently
> > > > from the ones that people do use.
> > > >
> > >
> > > This is a great point, though I'd ask, is ChromeVox high enough
> fidelity
> > > that it would be useful? Is it so different that it'd be harmful, and
> in
> > > what ways?
> > >
> > > I'll hold criticism for the moment as the course materials are not up
> > yet,
> > > > but alarm bells are ringing...
> > > >
> > > > -Alastair
> > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > >

From: Olaf Drümmer
Date: Wed, Sep 11 2013 9:50AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

So given the exclusive focus on visually impaired user using a screen reader is a bit narrow, when all types of other disabilities and non screen reader AT are left out - how can it matter whether ChromeVox is used instead of NVDA/VoiceOver/JAWS/... and at the same it does not matter that other types of disability and other types of AT are not even thought of?

Aren't we all still blind [pun intended] to disabilities and AT beyond the blind user/screen reader combo?

To me, this is like arguing about what is the best car stereo model while ignoring the car's wheels are still missing.

Olaf


Am 11 Sep 2013 um 17:09 schrieb Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = >:

> Just remember that Chrome Vox use, as reported by the latest WebAIM
> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
> around 14% and Jaws still in the 50% range.
> As long as screen readers and standards play nice (and there is
> consistency regarding the interpretation and support of standards)
> this should not matter too much, but when screen reading applications
> support standards partially, or come up with their own set of rules
> and best practices, people need to at least be aware of the fact that
> if they test with a screen reader with very small userbase and that
> has its own take on how to most accessibly acquire and communicate
> info, this could lead to a lot of frustration and inconsistencies in
> how the developer experiences problems and how the users do. So from
> that perspective, NVDA would be a lot more useful than Chrome Vox
> (this is just a general statement, I have not tried using Chrome Vox
> myself, it is on my ever-lengthening to-do list).
> I am curious to see what the Google accessibility course will be like
> and, moreover, if the course is accessible to a screen reader user (it
> better be, else that would be embarrassing for them to say the least).
> Cheers
> -Birkir
> Birkir Gunnarsson
> Accessibility Subject Matter Expert | Deque Systems
>
>
>
>
> On 9/11/13, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>> Cameron wrote:
>>> it is a black box with regards to its API
>>
>> There is an accessibility inspector that's part of Xcode, if you are on the
>> OSX development programme thingy. I assume that would show you the
>> attributes in the tables Steve mentioned.
>>
>> -Alastair
>> >> >> >>
> > >

From: Birkir R. Gunnarsson
Date: Wed, Sep 11 2013 10:18AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

HI Olaf

Oh, I perfectly agree with you, and in all my testing and evaluations
I put great emphasis on making sure I am not a screen reader tester.
The market for accessibility is huge, everybody experiences visual
impairment, hearing impairment and various cognitive issues (small
device, noisy environment, multi tasking/cognitive overload),
especially on mobile devices, so making a website that works for
everybody is the goal.
My pointing out the screen reader difference had only to do with the
screen reader emphasis of the course and discussion, and my assumption
(at lesat hope) is that Google will launch other courses focused on
other types of disabilities and usability issues.


On 9/11/13, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
> So given the exclusive focus on visually impaired user using a screen reader
> is a bit narrow, when all types of other disabilities and non screen reader
> AT are left out - how can it matter whether ChromeVox is used instead of
> NVDA/VoiceOver/JAWS/... and at the same it does not matter that other types
> of disability and other types of AT are not even thought of?
>
> Aren't we all still blind [pun intended] to disabilities and AT beyond the
> blind user/screen reader combo?
>
> To me, this is like arguing about what is the best car stereo model while
> ignoring the car's wheels are still missing.
>
> Olaf
>
>
> Am 11 Sep 2013 um 17:09 schrieb Birkir R. Gunnarsson
> < = EMAIL ADDRESS REMOVED = >:
>
>> Just remember that Chrome Vox use, as reported by the latest WebAIM
>> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
>> around 14% and Jaws still in the 50% range.
>> As long as screen readers and standards play nice (and there is
>> consistency regarding the interpretation and support of standards)
>> this should not matter too much, but when screen reading applications
>> support standards partially, or come up with their own set of rules
>> and best practices, people need to at least be aware of the fact that
>> if they test with a screen reader with very small userbase and that
>> has its own take on how to most accessibly acquire and communicate
>> info, this could lead to a lot of frustration and inconsistencies in
>> how the developer experiences problems and how the users do. So from
>> that perspective, NVDA would be a lot more useful than Chrome Vox
>> (this is just a general statement, I have not tried using Chrome Vox
>> myself, it is on my ever-lengthening to-do list).
>> I am curious to see what the Google accessibility course will be like
>> and, moreover, if the course is accessible to a screen reader user (it
>> better be, else that would be embarrassing for them to say the least).
>> Cheers
>> -Birkir
>> Birkir Gunnarsson
>> Accessibility Subject Matter Expert | Deque Systems
>>
>>
>>
>>
>> On 9/11/13, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>>> Cameron wrote:
>>>> it is a black box with regards to its API
>>>
>>> There is an accessibility inspector that's part of Xcode, if you are on
>>> the
>>> OSX development programme thingy. I assume that would show you the
>>> attributes in the tables Steve mentioned.
>>>
>>> -Alastair
>>> >>> >>> >>>
>> >> >> >
> > > >

From: Alastair Campbell
Date: Wed, Sep 11 2013 11:40AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Birkir R. Gunnarsson wrote:

> Just remember that Chrome Vox use, as reported by the latest WebAIM
> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
> around 14% and Jaws still in the 50% range.


Whilst completely agreeing with Olaf's comment about priorities (missing
the wheels!), I think more people should notice how much VoiceOver on iOS
is used these days.

From the Webaim survey [1], VoiceOver on iOS is the second most used
screenreader at around 42% of people who answered.

I base that on 72% of people using a mobile screenreader, and of those
58.5% use iOS. Therefore 42% use VoiceOver on iOS.

Now, it is not necessarily the primary screenreader by any means, and you
could argue that people use apps more than the browser, but still, makes
you think!

I checked back on that stat after talking to several regular screen reader
users who said things like "I don't bother opening the laptop much anymore,
I just use my iPhone".

It would be interesting to include VoiceOver/iOS as an option for "primary
screen reader" next year.

1] http://webaim.org/projects/screenreadersurvey4/#mobile

-Alastair

From: George Zamfir
Date: Wed, Sep 11 2013 12:13PM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

I will repost here from
Google+<https://plus.google.com/100697095765158521187/posts/gGzjCGdTm8M>my
take on this.

Google team, you are commendable for this initiative and I applaud you for
this. Unfortunately it just doesn't cut it in its current form.

There are 2 big issues with what this course is projecting and Google's
overall message with regards to accessibility:

1. "Introduction to Web Accessibility" - generic at best and misleading at
worst.

Really, the title should be "Introduction to Web Accessibility with Chrome
/ ChromeVox". Also, it should be made crystal clear that the course teaches
accessibility for one type of assistive technologies - screen readers -
more specifically for ChromeVox with Chrome.

Students might think that this course will teach them web accessibility
when in fact they only learn about a subset. They should be made aware that
"Introduction to Web Accessibility" is specific to Google products - Chrome
& ChromeVox and that what they learn may not apply to other screen readers,
let alone other assistive technologies or browsers.

Marco Zehe makes very pertinent points about ChromeVox: (
http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/):
"
Here’s the big problem: ChromeVox uses DOM access exclusively to provide
access to web content to blind users. It does, as far as I could tell, not
use any of Chrome’s own accessibility APIs...

If you are a web developer, you can imagine what this means! Even if you go
through the trouble of testing your web site with Chrome and Safari to make
sure they expose their information to VoiceOver, it is not guaranteed that
ChromeVox users will benefit, too. Likewise, if you use chromeVox
exclusively, you have no certainty that the other APIs are able to cope
with your content.

Web developers on Windows have also learned these lessons the hard way with
different screen readers in different browsers: Because with IE, each is
forced to do their own interpretation of HTML, at least on some level,
results will undoubtedly differ.
"

The accessibility community has been working relentlessly to eliminate this
dogma, that accessibility is only for visual impairments and by extension
only for screen readers. With the way this course is presented you are
basically promoting this dogma and really squash the existing efforts.


2. Not following your own advice - do as I say not as I do!

Here's one example: Lesson 1.2 Capture Semantics and Structure in Your HTML
- Avoid Div Soup and Span Salad (course page:
https://webaccessibility.withgoogle.com/unit?unit=1&lesson=5, video:
http://youtu.be/_cDz0tdBjrU).

And then your own products are built with nothing but <div>s, here's a
screenshot of Gmail: http://t.co/X8HUOMrZzM. Same markup since 2011:
http://t.co/Zu7JHGaYT8.

You can see here the image you're projecting on yourself as a company. Do
as I say not as I do.


-- Summary of the 2 points above:
As an accessibility professional (goodwally.ca) and organizer of
accessibility meetups (meetup.com/a11yTO) I cannot in good conscience
recommend this course to my members in its current form. The current form
being potentially misleading and specific to Google products.


3. Heavy reliance on ARIA-solutions as the primary solution

This extra point, is really an over-arching theme that is certainly not
specific to Google along. But it's certainly something that Google is a big
proponent of. But I think the point is even bigger than the 2 above as it
is a growing trend. Let me explain:

Further to point #2 above, in order to make up for the "Div Soup" on the
Google products
it's being resorting to heavy ARIA use. Which of course breaks the 1st rule
of ARIA (quoting from
http://blog.paciellogroup.com/2012/06/html5-accessibility-chops-using-aria-notes
):

"
First rule of ARIA:
If you can use a native HTML element or attribute instead of an ARIA role,
state or property, then do so.

Under what circumstances may this not be possible?
- If the visual design constraints rule out the use of a particular native
element, because the element cannot be styled as required.
- If the feature is not currently available in HTML.
- If the feature is available in HTML but it is not implemented or it is
implemented, but accessibility support is not.
"

Furthermore, any ARIA-only solution may not accessible to users who simply
don't have support for ARIA, maybe they have an older browser or screen
reader, etc. And of course, ARIA has practical use only for screen readers
today, which is but 1 type of assistive technologies (AT). There are other
ATs like voice command software (voice-to-text, e.g. Dragon
NaturallySpeaking) that simply won't work because they don't support ARIA.
So, practically Dragon users cannot directly activate a "fake" button.

Bottom-line: the message being transmitted is that it is OK to write
non-semantic markup, patch it up with ARIA and call it accessible. That is
the wrong message coming from an internet giant.


-- Please note that my comments above are not directed at any one
individual / team or the quality of the course contents. As I said the
accessibility team is to be commendable for the course. Also, I'm a big
supporter for ARIA when used correctly.


--
*George Zamfir*
*e:* = EMAIL ADDRESS REMOVED =
*t:* 416-875-0176
*

meetup.com/a11yTO <http://meetup.com/a11yTO%E2%80%8B>;* - Toronto
Accessibility & Inclusive Design
*goodwally.ca* - "W
e are as abled as the web environment
around
us!
"

From: Karl Groves
Date: Thu, Sep 12 2013 7:39AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Not responding to anyone in particular so much as the general hoopla over
this course, especially considering nobody has actually seen it yet.

That's not to say that people are wrong in voicing concern over the
description of the course indicating that it is Chrome-specific and aimed
at a11y for the blind & visually impaired. But let me ask this: Do you
think that Deque's courses aren't gonna discuss Worldspace or SSB's courses
aren't going to talk about AMP? HiSoftware wouldn't talk about Compliance
Sherriff? And actually, if you haven't tried Chrome's Dev Tools and the
accessibility testing capabilities it has, maybe you should.

Additionally, let's step back and look at what this course could do.
First, I think everyone universally agrees that accessibility problems are
best avoided. How does that happen? By educating developers. "This free,
online course from Google's Accessibility team is targeted at devs and
others who work using Chrome." Google has an incredible reach in the
developer community. The Google Developers channel on YouTube has more than
350,000 subscribers. I have no idea how many people take courses like this,
but I'm guessing that if they push it hard they can get a ton of sign-ups.
In other words, despite its assumed flaws, this course has the potential
to reach out and engage far more developers than anyone else.

This community has a terrible habit of being hyper-judgmental of anything
that comes short of perfection. The damn course hasn't even been released
yet and the virtiol leveled at Google is already ridiculous. Here's an
alternate idea: maybe as a community, we should embrace Google for their
efforts and help them market the hell out of it. Then attend the course
yourselves and take note of things you want to see improved. Send your list
to TV Raman and then thank him for reaching out to developers to make the
web a better place for all.


On Wed, Sep 11, 2013 at 1:40 PM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> Birkir R. Gunnarsson wrote:
>
> > Just remember that Chrome Vox use, as reported by the latest WebAIM
> > screen reader survey, was less then .5%, Voiceover around 12%, NVDA
> > around 14% and Jaws still in the 50% range.
>
>
> Whilst completely agreeing with Olaf's comment about priorities (missing
> the wheels!), I think more people should notice how much VoiceOver on iOS
> is used these days.
>
> From the Webaim survey [1], VoiceOver on iOS is the second most used
> screenreader at around 42% of people who answered.
>
> I base that on 72% of people using a mobile screenreader, and of those
> 58.5% use iOS. Therefore 42% use VoiceOver on iOS.
>
> Now, it is not necessarily the primary screenreader by any means, and you
> could argue that people use apps more than the browser, but still, makes
> you think!
>
> I checked back on that stat after talking to several regular screen reader
> users who said things like "I don't bother opening the laptop much anymore,
> I just use my iPhone".
>
> It would be interesting to include VoiceOver/iOS as an option for "primary
> screen reader" next year.
>
> 1] http://webaim.org/projects/screenreadersurvey4/#mobile
>
> -Alastair
> > > >



--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

From: Denis Boudreau
Date: Thu, Sep 12 2013 9:05AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Hey,

I gotta say I agree with you Karl.

I was one of those who complained about this as soon as I saw it (mea maxima culpa), and even though I was immediately thankful for Google for actually doing this (their reach is indeed far greater and that's ultimately a good thing for the field because more devs are going to hear about it), I was bothered - scratch that - pissed off by the fact that while we spend so much time and energy widening the scope to include other types of disabilities, all of a sudden, Google would come in with their big corporate resources and walk all over our efforts and narrow it down again. So that pissed me off, I have to admit.

Then, as I discussed with people that are much wiser than I'll probably ever be (waving at you JF), I came to realize that Google can get a lot more traction than we ever will as individual cogs in the a11y wheel. So maybe they can succeed at drawing new people to the field, something we very much struggle to do on our own. So, a lot of positive can indeed come out of this.

It's no coincidence that Google is offering this free training now - their goal is most probably to widen their userbase both in terms of developers relying on ChromeVox and end users actually trying it, and they want the best, positive corporate image they can have (who wouldn't).

The context is changing and with all the legal and government requirements falling into place all over the world and especially in the US, there's certainly an interest in making sure developers that are going to have to learn about this accessibility stuff anyway actually learn about it the way Google wants them to learn it: using Chrome, ChromeVoX and relying on their developer tools. If I was investing in Chrome and wanted to reverse the shift in the screen reader userbase, this is exactly what I'd do too. What better way to bring more people to an emerging solution such as ChromeVox, as Jaws and Window-Eyes shares are being progressively divided between VoiceOVer and NVDA? Google wants a piece of it too. Can't blame them for that.

Indeed, Google's tools and resources are awesome and indeed a lot (most?) developers use Chrome, so it makes perfect sense to offer them tools they can simply integrate to their current tool set. Indeed, they are very much oriented towards their own products and the gain they can get from the whole thing. This is a business after all, and we need to remember that the bottom line is what matters most. So, I've come to the conclusion that it doesn't matter so much how Google approaches it, as long as they do approach it. I believe we can trust them to say the right things after all. They'll probably put way too much emphasis on way-aria, might even diminish the importance of semantic markup in the process (love those checkbox roles on spans, right!), but it will expose more devs to our cause. And that's ultimately a good thing. But there's another potential problem looming.

We all want more people to hear about accessibility, and if I had to choose, I'd rather spend the next 5 years of my life widening the understanding of developers who were in contact with this training to include other types of disabilities, rather than keep trying to raise awareness in order to bring new people to accessibility. But I do see a potential problem here. As more devs learn about a11y the Google way, there will be an even bigger push on more recent technologies such as wai-aria for instance. And that might result in a widening in the digital gap for end users who only have access to old version of assistive technology that don't support aria. That means that initially, some users who do not have a recent version of a screen reader will be left behind. Those will probably need to upgrade more than they'd want to, and there will be tools available to them for free. If some of them can't upgrade to the latest version of Jaws and decide to give ChromeVox a try, I don
't think anyone at Google will mind.

But, the one thing that worries me here is that developers who lear about a11y the Google way are going to start building sites that are accessible to a screen reader used mostly by developers (Chromevox), while the real end users will still be using the other, more prominent screen readers with which those same developers will not have tested their content with (jaws, nvda, etc.). This means that the user experience of those who build will look good, while the user experience who those in the receiving end might be shakier... It would suck to come to a point where there's developer accessibility and end user accessibility. And that's very much a possibility, unless the devs trained with the Google tools actually widen their horizons by integrating other tools in their tool set.

Whether we like it or not, this effort on Google's part will have a considerable impact on the work we do. Most of it good, some of it maybe not so much. As Google keeps its focus on visual disabilities, the rest of us will have to make sure we spend the next few years expanding the a11y horizons of the new folks Google trained in (the otherwise rather narrowed down field of) blind/screen reader accessibility.

But when I analyze the whole thing coldly, I think the perspective of expanding the understanding of developers to view accessibility as a more than just the blind over the next few years is still more interesting than the perspective of continuing to talk about alt text to developers who've never heard of accessibility.

So with a few caveats I have now come to think that this is indeed a good thing for our field and am grateful to Google for deciding to invest their resources into this. Nobody else could have done this. I can't help be worried of the impact, but it would be no different if any other vendor with interest in a marginal screen reader solution had done the same.

While I agree that any vendor with an interest in accessibility would be biased in such a training offer, I still see a huge difference in terms of potential impact for end users when that vendor happens to develop a screen reader barely none of those end users are currently using. I don't think we'd face similar issues with SSB, HiSoft, Deque or IBM for instance.

But I want to acknowledge the positive in all this and for that, I want to both apologize to Google for bitching about it in the first place and thank them for offering something that puts us on the path of a broader exposure for web accessibility.

/Denis






On 2013-09-12, at 9:39 AM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:

> Not responding to anyone in particular so much as the general hoopla over
> this course, especially considering nobody has actually seen it yet.
>
> That's not to say that people are wrong in voicing concern over the
> description of the course indicating that it is Chrome-specific and aimed
> at a11y for the blind & visually impaired. But let me ask this: Do you
> think that Deque's courses aren't gonna discuss Worldspace or SSB's courses
> aren't going to talk about AMP? HiSoftware wouldn't talk about Compliance
> Sherriff? And actually, if you haven't tried Chrome's Dev Tools and the
> accessibility testing capabilities it has, maybe you should.
>
> Additionally, let's step back and look at what this course could do.
> First, I think everyone universally agrees that accessibility problems are
> best avoided. How does that happen? By educating developers. "This free,
> online course from Google's Accessibility team is targeted at devs and
> others who work using Chrome." Google has an incredible reach in the
> developer community. The Google Developers channel on YouTube has more than
> 350,000 subscribers. I have no idea how many people take courses like this,
> but I'm guessing that if they push it hard they can get a ton of sign-ups.
> In other words, despite its assumed flaws, this course has the potential
> to reach out and engage far more developers than anyone else.
>
> This community has a terrible habit of being hyper-judgmental of anything
> that comes short of perfection. The damn course hasn't even been released
> yet and the virtiol leveled at Google is already ridiculous. Here's an
> alternate idea: maybe as a community, we should embrace Google for their
> efforts and help them market the hell out of it. Then attend the course
> yourselves and take note of things you want to see improved. Send your list
> to TV Raman and then thank him for reaching out to developers to make the
> web a better place for all.
>
>
> On Wed, Sep 11, 2013 at 1:40 PM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Birkir R. Gunnarsson wrote:
>>
>>> Just remember that Chrome Vox use, as reported by the latest WebAIM
>>> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
>>> around 14% and Jaws still in the 50% range.
>>
>>
>> Whilst completely agreeing with Olaf's comment about priorities (missing
>> the wheels!), I think more people should notice how much VoiceOver on iOS
>> is used these days.
>>
>> From the Webaim survey [1], VoiceOver on iOS is the second most used
>> screenreader at around 42% of people who answered.
>>
>> I base that on 72% of people using a mobile screenreader, and of those
>> 58.5% use iOS. Therefore 42% use VoiceOver on iOS.
>>
>> Now, it is not necessarily the primary screenreader by any means, and you
>> could argue that people use apps more than the browser, but still, makes
>> you think!
>>
>> I checked back on that stat after talking to several regular screen reader
>> users who said things like "I don't bother opening the laptop much anymore,
>> I just use my iPhone".
>>
>> It would be interesting to include VoiceOver/iOS as an option for "primary
>> screen reader" next year.
>>
>> 1] http://webaim.org/projects/screenreadersurvey4/#mobile
>>
>> -Alastair
>> >> >> >>
>
>
>
> --
>
> Karl Groves
> www.karlgroves.com
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
> > >

From: Walt Stover
Date: Thu, Sep 12 2013 9:36AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

If I might add a thought. As a screen reader user and tester, I have
tested google with chromevox and what google claims that chromevox
provides is not true. I had better with voice over and chrome than
with chrome and chromevox. The testing that I have done is with JAWS,
NVDA and voice over and yes chromevox. Chromevox has so many bells
and whistles that it is not user friendly. Google wants everyone to
use their short keys but as a person with limited dexterity this is
very difficult to do. Google has unlimited potential but they are no
where close to realizing their potential in my opinion.
Walt Stover

On 9/12/13, Denis Boudreau < = EMAIL ADDRESS REMOVED = > wrote:
> Hey,
>
> I gotta say I agree with you Karl.
>
> I was one of those who complained about this as soon as I saw it (mea maxima
> culpa), and even though I was immediately thankful for Google for actually
> doing this (their reach is indeed far greater and that's ultimately a good
> thing for the field because more devs are going to hear about it), I was
> bothered - scratch that - pissed off by the fact that while we spend so much
> time and energy widening the scope to include other types of disabilities,
> all of a sudden, Google would come in with their big corporate resources and
> walk all over our efforts and narrow it down again. So that pissed me off, I
> have to admit.
>
> Then, as I discussed with people that are much wiser than I'll probably ever
> be (waving at you JF), I came to realize that Google can get a lot more
> traction than we ever will as individual cogs in the a11y wheel. So maybe
> they can succeed at drawing new people to the field, something we very much
> struggle to do on our own. So, a lot of positive can indeed come out of
> this.
>
> It's no coincidence that Google is offering this free training now - their
> goal is most probably to widen their userbase both in terms of developers
> relying on ChromeVox and end users actually trying it, and they want the
> best, positive corporate image they can have (who wouldn't).
>
> The context is changing and with all the legal and government requirements
> falling into place all over the world and especially in the US, there's
> certainly an interest in making sure developers that are going to have to
> learn about this accessibility stuff anyway actually learn about it the way
> Google wants them to learn it: using Chrome, ChromeVoX and relying on their
> developer tools. If I was investing in Chrome and wanted to reverse the
> shift in the screen reader userbase, this is exactly what I'd do too. What
> better way to bring more people to an emerging solution such as ChromeVox,
> as Jaws and Window-Eyes shares are being progressively divided between
> VoiceOVer and NVDA? Google wants a piece of it too. Can't blame them for
> that.
>
> Indeed, Google's tools and resources are awesome and indeed a lot (most?)
> developers use Chrome, so it makes perfect sense to offer them tools they
> can simply integrate to their current tool set. Indeed, they are very much
> oriented towards their own products and the gain they can get from the whole
> thing. This is a business after all, and we need to remember that the bottom
> line is what matters most. So, I've come to the conclusion that it doesn't
> matter so much how Google approaches it, as long as they do approach it. I
> believe we can trust them to say the right things after all. They'll
> probably put way too much emphasis on way-aria, might even diminish the
> importance of semantic markup in the process (love those checkbox roles on
> spans, right!), but it will expose more devs to our cause. And that's
> ultimately a good thing. But there's another potential problem looming.
>
> We all want more people to hear about accessibility, and if I had to choose,
> I'd rather spend the next 5 years of my life widening the understanding of
> developers who were in contact with this training to include other types of
> disabilities, rather than keep trying to raise awareness in order to bring
> new people to accessibility. But I do see a potential problem here. As more
> devs learn about a11y the Google way, there will be an even bigger push on
> more recent technologies such as wai-aria for instance. And that might
> result in a widening in the digital gap for end users who only have access
> to old version of assistive technology that don't support aria. That means
> that initially, some users who do not have a recent version of a screen
> reader will be left behind. Those will probably need to upgrade more than
> they'd want to, and there will be tools available to them for free. If some
> of them can't upgrade to the latest version of Jaws and decide to give
> ChromeVox a try, I don
> 't think anyone at Google will mind.
>
> But, the one thing that worries me here is that developers who lear about
> a11y the Google way are going to start building sites that are accessible to
> a screen reader used mostly by developers (Chromevox), while the real end
> users will still be using the other, more prominent screen readers with
> which those same developers will not have tested their content with (jaws,
> nvda, etc.). This means that the user experience of those who build will
> look good, while the user experience who those in the receiving end might be
> shakier... It would suck to come to a point where there's developer
> accessibility and end user accessibility. And that's very much a
> possibility, unless the devs trained with the Google tools actually widen
> their horizons by integrating other tools in their tool set.
>
> Whether we like it or not, this effort on Google's part will have a
> considerable impact on the work we do. Most of it good, some of it maybe not
> so much. As Google keeps its focus on visual disabilities, the rest of us
> will have to make sure we spend the next few years expanding the a11y
> horizons of the new folks Google trained in (the otherwise rather narrowed
> down field of) blind/screen reader accessibility.
>
> But when I analyze the whole thing coldly, I think the perspective of
> expanding the understanding of developers to view accessibility as a more
> than just the blind over the next few years is still more interesting than
> the perspective of continuing to talk about alt text to developers who've
> never heard of accessibility.
>
> So with a few caveats I have now come to think that this is indeed a good
> thing for our field and am grateful to Google for deciding to invest their
> resources into this. Nobody else could have done this. I can't help be
> worried of the impact, but it would be no different if any other vendor with
> interest in a marginal screen reader solution had done the same.
>
> While I agree that any vendor with an interest in accessibility would be
> biased in such a training offer, I still see a huge difference in terms of
> potential impact for end users when that vendor happens to develop a screen
> reader barely none of those end users are currently using. I don't think
> we'd face similar issues with SSB, HiSoft, Deque or IBM for instance.
>
> But I want to acknowledge the positive in all this and for that, I want to
> both apologize to Google for bitching about it in the first place and thank
> them for offering something that puts us on the path of a broader exposure
> for web accessibility.
>
> /Denis
>
>
>
>
>
>
> On 2013-09-12, at 9:39 AM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Not responding to anyone in particular so much as the general hoopla over
>> this course, especially considering nobody has actually seen it yet.
>>
>> That's not to say that people are wrong in voicing concern over the
>> description of the course indicating that it is Chrome-specific and aimed
>> at a11y for the blind & visually impaired. But let me ask this: Do you
>> think that Deque's courses aren't gonna discuss Worldspace or SSB's
>> courses
>> aren't going to talk about AMP? HiSoftware wouldn't talk about
>> Compliance
>> Sherriff? And actually, if you haven't tried Chrome's Dev Tools and the
>> accessibility testing capabilities it has, maybe you should.
>>
>> Additionally, let's step back and look at what this course could do.
>> First, I think everyone universally agrees that accessibility problems
>> are
>> best avoided. How does that happen? By educating developers. "This
>> free,
>> online course from Google's Accessibility team is targeted at devs and
>> others who work using Chrome." Google has an incredible reach in the
>> developer community. The Google Developers channel on YouTube has more
>> than
>> 350,000 subscribers. I have no idea how many people take courses like
>> this,
>> but I'm guessing that if they push it hard they can get a ton of
>> sign-ups.
>> In other words, despite its assumed flaws, this course has the potential
>> to reach out and engage far more developers than anyone else.
>>
>> This community has a terrible habit of being hyper-judgmental of anything
>> that comes short of perfection. The damn course hasn't even been released
>> yet and the virtiol leveled at Google is already ridiculous. Here's an
>> alternate idea: maybe as a community, we should embrace Google for their
>> efforts and help them market the hell out of it. Then attend the course
>> yourselves and take note of things you want to see improved. Send your
>> list
>> to TV Raman and then thank him for reaching out to developers to make the
>> web a better place for all.
>>
>>
>> On Wed, Sep 11, 2013 at 1:40 PM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Birkir R. Gunnarsson wrote:
>>>
>>>> Just remember that Chrome Vox use, as reported by the latest WebAIM
>>>> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
>>>> around 14% and Jaws still in the 50% range.
>>>
>>>
>>> Whilst completely agreeing with Olaf's comment about priorities (missing
>>> the wheels!), I think more people should notice how much VoiceOver on
>>> iOS
>>> is used these days.
>>>
>>> From the Webaim survey [1], VoiceOver on iOS is the second most used
>>> screenreader at around 42% of people who answered.
>>>
>>> I base that on 72% of people using a mobile screenreader, and of those
>>> 58.5% use iOS. Therefore 42% use VoiceOver on iOS.
>>>
>>> Now, it is not necessarily the primary screenreader by any means, and
>>> you
>>> could argue that people use apps more than the browser, but still, makes
>>> you think!
>>>
>>> I checked back on that stat after talking to several regular screen
>>> reader
>>> users who said things like "I don't bother opening the laptop much
>>> anymore,
>>> I just use my iPhone".
>>>
>>> It would be interesting to include VoiceOver/iOS as an option for
>>> "primary
>>> screen reader" next year.
>>>
>>> 1] http://webaim.org/projects/screenreadersurvey4/#mobile
>>>
>>> -Alastair
>>> >>> >>> >>>
>>
>>
>>
>> --
>>
>> Karl Groves
>> www.karlgroves.com
>> @karlgroves
>> http://www.linkedin.com/in/karlgroves
>> Phone: +1 410.541.6829
>> >> >> >
> > > >

From: Alastair Campbell
Date: Thu, Sep 12 2013 10:05AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Hi Karl,

I hope I didn't come across as vitriolic, perhaps I should have started by
saying "this seems like a good thing for Google to be doing, but..."?

It tweaks a nerve as it appears to be compounding some issues I see at the
moment.

There are two aspects to this, the main one is framing. It is called
"Introduction to web accessibility", so I suspect that in a few months I
will meet developers who say (or at least thinks) "I know all about
accessibility, I did the course from Google".

That would be great, if the breadth were wider, or if it acknowledged that
there were other audiences. (I know it isn't all up yet, but the syllabus
overview is, and part 1 of 4 is, so we have a pretty good idea.)

If it was called "Improving accessibility for blind people with Google's
developers tools" I wouldn't have thought to comment. It says roughly that
in the introduction, but doesn't acknowledge there is anything else,
therefore developers might not think there is more to it.

You can see the result of this type of thinking in questions on
Stackoverflow, for example:
http://stackoverflow.com/questions/18500035/can-blind-people-use-web-pages-that-utilize-mouse-events-for-interactions/18521958#18521958
I"m not being critical of the questioner, this happens a lot and is
self-perpetuating, and not helped when enforced by large organisations.

I agree that Google will reach more people than anyone else, great! But if
they do and it's a one-off thing, when do improvements get made?

That first issue that is easy to fix, just frame it properly and make sure
people are aware there is more to it.

The second issue is related to Denis' comment about a developer screen
reader vs user screen readers. If ChromeVox were using the API as Marco
suggested, I would not have thought to comment.

I have no problem with Google requiring it's own tools as part of the
course, I use them myself (barring ChromeVox, which I will try). I can see
that using ChromeVox in this scenario is very effective as it's cross
platform, and if it were framed as 'testing to check you are meeting the
standards' that would be fine.

However, the course (part 1 at least) implies that is all that's needed,
even basic keyboard access without having a screen reader is not apparent,
and it does appear to fit into part 1. It is also consistent with Google's
approach to accessibility in general.

So, apologies if I came across as vitriolic, I think it is a very welcome
step from Google. I'm just frustrated that it is likely to compound some
issues I run into all the time.

-Alastair

From: Alastair Campbell
Date: Thu, Sep 12 2013 10:11AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Denis Boudreau wrote:

> But when I analyze the whole thing coldly, I think the perspective of
> expanding the understanding of developers to view accessibility as a more
> than just the blind over the next few years is still more interesting than
> the perspective of continuing to talk about alt text to developers who've
> never heard of accessibility.


That's interesting, and might be the root of different assumptions. I very
rarely meet developers who don't know about alt text and screen readers
(even if they haven't used one). The main things I need to get across is
the expansion to things like keyboard accessibility, magnification, and you
can use JavaScript but need to make it accessible...

We've had a pretty good web-standards and accessibility scene in the UK,
perhaps it's moved on a bit here and I get different issues?

-Alastair

From: Jennifer Sutton
Date: Thu, Sep 12 2013 10:56AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

For those who may be interested and have not seen, I thought I'd
share the link that shows the auditing tests that can be done with
Google's dev tools:

https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules

From: Bryan Garaventa
Date: Thu, Sep 12 2013 12:05PM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

In reading this, it looks good, but there are some areas that are of concern
to me.

The basic ARIA advice, such as adding role=button to Divs is correct.

It doesn't specify however, that supporting scripting must be added as well
to ensure functionality, otherwise the ARIA attributes added by themselves
will not ensure accessibility for screen reader and keyboard only users.

Within the section "Elements with onclick handlers must be focusable", it
specifies that it is good to add tabindex to a span with a click event.

It does not specify however, that a key event must also be added to ensure
keyboard accessibility, otherwise it will be impossible to press Enter on
the element to activate it. Instead, it says "Elements which have click
handlers but are not focusable can not be used by keyboard-only users.",
which is only partially correct.
Also, a valid ARIA role must be added to provide a textual role of the
element for screen reader users, such as role=button or role=link, otherwise
screen reader users will not be aware that the element is supposed to be an
active element.

These omissions will cause some very large accessibility issues to occur for
users of various Assistive Technologies when used in differing browser
combinations.



----- Original Message -----
From: "Jennifer Sutton" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, September 12, 2013 9:56 AM
Subject: Re: [WebAIM] for Chrome devs: intro to accessibility course


> For those who may be interested and have not seen, I thought I'd
> share the link that shows the auditing tests that can be done with
> Google's dev tools:
>
> https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules
>
>
>
> > >

From: Katie Haritos-Shea
Date: Thu, Sep 12 2013 12:18PM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Bravo all around!


Sent from my Samsung Galaxy Note® II



-------- Original message --------
From: Denis Boudreau < = EMAIL ADDRESS REMOVED = >
Date: 09/12/2013 11:06 AM (GMT-05:00)
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] for Chrome devs: intro to accessibility course


Hey,

I gotta say I agree with you Karl.

I was one of those who complained about this as soon as I saw it (mea maxima culpa), and even though I was immediately thankful for Google for actually doing this (their reach is indeed far greater and that's ultimately a good thing for the field because more devs are going to hear about it), I was bothered - scratch that - pissed off by the fact that while we spend so much time and energy widening the scope to include other types of disabilities, all of a sudden, Google would come in with their big corporate resources and walk all over our efforts and narrow it down again. So that pissed me off, I have to admit.

Then, as I discussed with people that are much wiser than I'll probably ever be (waving at you JF), I came to realize that Google can get a lot more traction than we ever will as individual cogs in the a11y wheel. So maybe they can succeed at drawing new people to the field, something we very much struggle to do on our own. So, a lot of positive can indeed come out of this.

It's no coincidence that Google is offering this free training now - their goal is most probably to widen their userbase both in terms of developers relying on ChromeVox and end users actually trying it, and they want the best, positive corporate image they can have (who wouldn't).

The context is changing and with all the legal and government requirements falling into place all over the world and especially in the US, there's certainly an interest in making sure developers that are going to have to learn about this accessibility stuff anyway actually learn about it the way Google wants them to learn it: using Chrome, ChromeVoX and relying on their developer tools. If I was investing in Chrome and wanted to reverse the shift in the screen reader userbase, this is exactly what I'd do too. What better way to bring more people to an emerging solution such as ChromeVox, as Jaws and Window-Eyes shares are being progressively divided between VoiceOVer and NVDA? Google wants a piece of it too. Can't blame them for that.

Indeed, Google's tools and resources are awesome and indeed a lot (most?) developers use Chrome, so it makes perfect sense to offer them tools they can simply integrate to their current tool set. Indeed, they are very much oriented towards their own products and the gain they can get from the whole thing. This is a business after all, and we need to remember that the bottom line is what matters most. So, I've come to the conclusion that it doesn't matter so much how Google approaches it, as long as they do approach it. I believe we can trust them to say the right things after all. They'll probably put way too much emphasis on way-aria, might even diminish the importance of semantic markup in the process (love those checkbox roles on spans, right!), but it will expose more devs to our cause. And that's ultimately a good thing. But there's another potential problem looming.

We all want more people to hear about accessibility, and if I had to choose, I'd rather spend the next 5 years of my life widening the understanding of developers who were in contact with this training to include other types of disabilities, rather than keep trying to raise awareness in order to bring new people to accessibility. But I do see a potential problem here. As more devs learn about a11y the Google way, there will be an even bigger push on more recent technologies such as wai-aria for instance. And that might result in a widening in the digital gap for end users who only have access to old version of assistive technology that don't support aria. That means that initially, some users who do not have a recent version of a screen reader will be left behind. Those will probably need to upgrade more than they'd want to, and there will be tools available to them for free. If some of them can't upgrade to the latest version of Jaws and decide to give ChromeVox a try, I don

't think anyone at Google will mind.

But, the one thing that worries me here is that developers who lear about a11y the Google way are going to start building sites that are accessible to a screen reader used mostly by developers (Chromevox), while the real end users will still be using the other, more prominent screen readers with which those same developers will not have tested their content with (jaws, nvda, etc.). This means that the user experience of those who build will look good, while the user experience who those in the receiving end might be shakier... It would suck to come to a point where there's developer accessibility and end user accessibility. And that's very much a possibility, unless the devs trained with the Google tools actually widen their horizons by integrating other tools in their tool set.

Whether we like it or not, this effort on Google's part will have a considerable impact on the work we do. Most of it good, some of it maybe not so much. As Google keeps its focus on visual disabilities, the rest of us will have to make sure we spend the next few years expanding the a11y horizons of the new folks Google trained in (the otherwise rather narrowed down field of) blind/screen reader accessibility.

But when I analyze the whole thing coldly, I think the perspective of expanding the understanding of developers to view accessibility as a more than just the blind over the next few years is still more interesting than the perspective of continuing to talk about alt text to developers who've never heard of accessibility.

So with a few caveats I have now come to think that this is indeed a good thing for our field and am grateful to Google for deciding to invest their resources into this. Nobody else could have done this. I can't help be worried of the impact, but it would be no different if any other vendor with interest in a marginal screen reader solution had done the same.

While I agree that any vendor with an interest in accessibility would be biased in such a training offer, I still see a huge difference in terms of potential impact for end users when that vendor happens to develop a screen reader barely none of those end users are currently using. I don't think we'd face similar issues with SSB, HiSoft, Deque or IBM for instance.

But I want to acknowledge the positive in all this and for that, I want to both apologize to Google for bitching about it in the first place and thank them for offering something that puts us on the path of a broader exposure for web accessibility.

/Denis






On 2013-09-12, at 9:39 AM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:

> Not responding to anyone in particular so much as the general hoopla over
> this course, especially considering nobody has actually seen it yet.
>
> That's not to say that people are wrong in voicing concern over the
> description of the course indicating that it is Chrome-specific and aimed
> at a11y for the blind & visually impaired. But let me ask this: Do you
> think that Deque's courses aren't gonna discuss Worldspace or SSB's courses
> aren't going to talk about AMP? HiSoftware wouldn't talk about Compliance
> Sherriff? And actually, if you haven't tried Chrome's Dev Tools and the
> accessibility testing capabilities it has, maybe you should.
>
> Additionally, let's step back and look at what this course could do.
> First, I think everyone universally agrees that accessibility problems are
> best avoided. How does that happen? By educating developers. "This free,
> online course from Google's Accessibility team is targeted at devs and
> others who work using Chrome." Google has an incredible reach in the
> developer community. The Google Developers channel on YouTube has more than
> 350,000 subscribers. I have no idea how many people take courses like this,
> but I'm guessing that if they push it hard they can get a ton of sign-ups.
> In other words, despite its assumed flaws, this course has the potential
> to reach out and engage far more developers than anyone else.
>
> This community has a terrible habit of being hyper-judgmental of anything
> that comes short of perfection. The damn course hasn't even been released
> yet and the virtiol leveled at Google is already ridiculous. Here's an
> alternate idea: maybe as a community, we should embrace Google for their
> efforts and help them market the hell out of it. Then attend the course
> yourselves and take note of things you want to see improved. Send your list
> to TV Raman and then thank him for reaching out to developers to make the
> web a better place for all.
>
>
> On Wed, Sep 11, 2013 at 1:40 PM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Birkir R. Gunnarsson wrote:
>>
>>> Just remember that Chrome Vox use, as reported by the latest WebAIM
>>> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
>>> around 14% and Jaws still in the 50% range.
>>
>>
>> Whilst completely agreeing with Olaf's comment about priorities (missing
>> the wheels!), I think more people should notice how much VoiceOver on iOS
>> is used these days.
>>
>> From the Webaim survey [1], VoiceOver on iOS is the second most used
>> screenreader at around 42% of people who answered.
>>
>> I base that on 72% of people using a mobile screenreader, and of those
>> 58.5% use iOS. Therefore 42% use VoiceOver on iOS.
>>
>> Now, it is not necessarily the primary screenreader by any means, and you
>> could argue that people use apps more than the browser, but still, makes
>> you think!
>>
>> I checked back on that stat after talking to several regular screen reader
>> users who said things like "I don't bother opening the laptop much anymore,
>> I just use my iPhone".
>>
>> It would be interesting to include VoiceOver/iOS as an option for "primary
>> screen reader" next year.
>>
>> 1] http://webaim.org/projects/screenreadersurvey4/#mobile
>>
>> -Alastair
>> >> >> >>
>
>
>
> --
>
> Karl Groves
> www.karlgroves.com<;http://www.karlgroves.com>;
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
> > >

From: George Zamfir
Date: Thu, Sep 12 2013 7:20PM
Subject: Re: "for Chrome devs: intro to accessibility course"
← Previous message | Next message →

So, what we are now saying is that maybe we should make a compromise and
accept this course as-is and hopefully it will turn out OK. Maybe this
"imperfect" (for lack of a better word) course is better than nothing and
maybe we're better off with more developers having limited knowledge of
accessibility (unknowingly limited) than what we have today.

I do not think that this is a compromise worth making. Also, it sets a
dangerous precedent (more below).

But regardless of my opinion, shall we go down this path I will definitely
support our communal decision and do my share of work to expand "the
understanding of developers to view accessibility as a more than just the
blind over the next few years", as Denis very well said. I consider myself
lucky to work in this industry and I look up to all of you (and others
outside this thread) in order for me to stand alone in my opinion.

I think we can all agree that this course introduces fragmentation - as we
now have, let's say "Google accessibility", focused on blind /
screen-reader / ARIA, which is obviously a subset of accessibility. This
can only lead to more fragmentation (how about a "Microsoft accessibility"
focused on motor / gestures, which is not far-fetched with the Kinect) or a
monopoly ("Google accessibility" becomes THE accessibility non-official
standard). Whether further fragmentation or monopoly, maybe this is a sign
of evolution for web accessibility and it's just one cycle that we're
seeing.

However, I can't help but draw parallels between this development and the
problem we had back in 1998 (or rather starting to address in 1998) where 2
other browser makers compromised on standards in order to find "new ways of
manipulating web documents". Of course, this is the story of Netscape &
Internet Explorer and how WaSP (http://www.webstandards.org) came to be.

The difference today is ARIA, this is our "new ways of manipulating web
documents". It is crystal clear to me that we're on this trend of using
ARIA as our weapon to manipulate HTML. I've worked on various projects with
respectable companies active in accessibility who completely disregarded
the HTML markup because "we'll fix it later with ARIA" or "yes, the
framework is not accessible but we'll use it anyway because ARIA". What's
surprising to me is seeing the same attitude among accessibility
professionals. Who cares whether we use a DIV or a BUTTON when ARIA can
change the role anyway? Especially as long as it is WCAG-conformant...
We've stretched the use of ARIA (Accessible Rich Internet
Applications) from RIA (Rich Internet Applications) to damn buttons and
links, we've let this happen slowly but surely. ARIA used to be the
advanced topic, the stuff you use on those RIAs because there was no HTML
equivalent. Now ARIA is on page 1, semantic markup, WCAG & the HTML spec
footnotes.

The dangerous precedent is that we're encouraging the use and teaching of
ARIA as THE web accessibility standard & solution. Google not only fully
endorses this ARIA direction (based on how all of their products are built)
but will now teach it as being the de-facto web accessibility (of course
Google is not the only one). Yes, the full courses are not posted but the
first page of Unit 1 - Introduction mentions ARIA (Jared tweeted this: "If
the first page references aria-labelledby and DOM references (and defines
neither), it is NOT an "introduction" to web a11y") and unit 3 is "Using
Live Regions". I think this is a pretty good indicator of the ARIA
direction.

Yes, it's not quite 1998 but it has the potential to be. Maybe WaSP
shouldn't have been retired just yet.

I thought we should be exploring ARIA options after the HTML, CSS &
JavaScript options are exhausted (Progressive Enhancement, like Aaron
Gustafson says). That the primary solution we recommend our clients and
colleagues shouldn't default to ARIA. I've heard arguments from several
people that this is naive and a dated concept (I don't know what that makes
Aaron), that we should jump on ARIA whenever and wherever we get the chance
and really force / encourage others (browsers, AT, etc.) to improve support
for it. Because it's not accessible until it's ARIA-accessible.

If our communal agreement is that the paragraph above is true then I'll
apologize for encouraging this "boycott" (as someone said to me), I'll step
back and re-align my perspective on ARIA and you can consider the above bad
fiction.

To go back to my original message, the above is about point #3 which I
believe is the most important. But with regards to points #1 & #2, I still
consider them to be valid and I haven't read anything saying otherwise:
1. The title - "Introduction to Web Accessibility" - is generic at best and
misleading at worst
2. Double standard - do as I say not what I do.


--
*George Zamfir*
*e:* = EMAIL ADDRESS REMOVED =
*t:* 416-875-0176
*

meetup.com/a11yTO <http://meetup.com/a11yTO%E2%80%8B>;* - Toronto
Accessibility & Inclusive Design
*goodwally.ca* - "W
e are as abled as the web environment
around
us!
"

From: Patrick H. Lauke
Date: Fri, Sep 13 2013 1:41AM
Subject: Re: "for Chrome devs: intro to accessibility course"
← Previous message | Next message →

On 13/09/2013 02:20, George Zamfir wrote:
> So, what we are now saying is that maybe we should make a compromise and
> accept this course as-is and hopefully it will turn out OK. Maybe this
> "imperfect" (for lack of a better word) course is better than nothing and
> maybe we're better off with more developers having limited knowledge of
> accessibility (unknowingly limited) than what we have today.
>
> I do not think that this is a compromise worth making. Also, it sets a
> dangerous precedent (more below).

Ok, so we either have courses that are holistic and cover all areas of
accessibility, all tools, all browsers...or nothing at all! Hmmm

> I think we can all agree that this course introduces fragmentation - as we
> now have, let's say "Google accessibility", focused on blind /
> screen-reader / ARIA, which is obviously a subset of accessibility. This
> can only lead to more fragmentation (how about a "Microsoft accessibility"
> focused on motor / gestures, which is not far-fetched with the Kinect) or a
> monopoly ("Google accessibility" becomes THE accessibility non-official
> standard). Whether further fragmentation or monopoly, maybe this is a sign
> of evolution for web accessibility and it's just one cycle that we're
> seeing.

That ship has already sailed. For better or worse, when you mention
"accessibility" to a developer the first thing that comes to their mind
is blind users with screenreaders, partly because that's the most
technically demanding situation (and in many ways more deterministic and
easy to grasp from a dev's point of view compared to, say, changes to
actual content that need to be made for certain aspects of cognitive
disabilities).


> The difference today is ARIA, this is our "new ways of manipulating web
> documents". It is crystal clear to me that we're on this trend of using
> ARIA as our weapon to manipulate HTML. I've worked on various projects with
> respectable companies active in accessibility who completely disregarded
> the HTML markup because "we'll fix it later with ARIA" or "yes, the
> framework is not accessible but we'll use it anyway because ARIA". What's
> surprising to me is seeing the same attitude among accessibility
> professionals. Who cares whether we use a DIV or a BUTTON when ARIA can
> change the role anyway? Especially as long as it is WCAG-conformant...

There ARE situations outside of developer's control: clunky content
management systems that don't allow for certain markup to be used; 3rd
party frameworks and widgets that the devs can't modify; having to work
with templates that have been mandated and cannot be altered; etc. In
those situations, ARIA can be used to re-inject the correct semantics
into inappropriate markup. But yes, devs will also abuse this tech, like
they do any other tech.

And it's not about WCAG-conformant, but results-driven: can users still
get the meaning/functionality. Ultimately, that's what matters, rather
than semantic purity.

> We've stretched the use of ARIA (Accessible Rich Internet
> Applications) from RIA (Rich Internet Applications) to damn buttons and
> links, we've let this happen slowly but surely. ARIA used to be the
> advanced topic, the stuff you use on those RIAs because there was no HTML
> equivalent. Now ARIA is on page 1, semantic markup, WCAG & the HTML spec
> footnotes.

So we're bemoaning the fact that it's not an advanced, hidden topic
anymore? Again, results-driven!

> The dangerous precedent is that we're encouraging the use and teaching of
> ARIA as THE web accessibility standard & solution. Google not only fully
> endorses this ARIA direction (based on how all of their products are built)
> but will now teach it as being the de-facto web accessibility (of course
> Google is not the only one). Yes, the full courses are not posted but the
> first page of Unit 1 - Introduction mentions ARIA (Jared tweeted this: "If
> the first page references aria-labelledby and DOM references (and defines
> neither), it is NOT an "introduction" to web a11y") and unit 3 is "Using
> Live Regions". I think this is a pretty good indicator of the ARIA
> direction.

Perhaps, just perhaps, the examples they'll show will also fall under
the category of dynamic, interactive experiences where those ARIA
attributes are actually necessary. I somehow doubt that Google's course
will go through lots of static page examples and will instead focus on
AJAX-y web-app-like examples.

Anyway, please all carry on condemning the Google initiative for its
inaccuracies, as that seems to be what we as a community are good
at...rather than seeing it as a positive step, we're quite happy to slam
it for not being comprehensive enough.



P
--
Patrick H. Lauke

From: Bryan Garaventa
Date: Fri, Sep 13 2013 11:10AM
Subject: Re: "for Chrome devs: intro to accessibility course"
← Previous message | Next message →

Emotional responses aside, George does bring up valid points, and it's not a
matter of condemning Google or anyone else for exploring efforts in
accessibility.

The range of responses to this topic are sort of interesting, going from
instant support without verification to, as you said, condemnation.

The first one seems to indicate that people are more likely to support what
is most popular instead of what is most accessible; the bandwagon effect,
and the second muddies the waters by focusing on a company rather than a
solution.

The biggest problem here is the assertion that accessibility can be
accurately determined using only one browser with one AT, and this is simply
incorrect.

For example, a year ago, I discovered some ARIA bugs using an iPhone that I
wished to report to Apple using their bug tracking system.
To do this, I needed to sign up for an account on their system, and as it
turned out, it was literally impossible to do using IE, Firefox, or Chrome.
I tried to do it in all three, and every time the form would not submit
properly, throwing an error.
I contacted support and opened a trouble ticket, providing precise steps to
reproduce and including the browser and versions I was using at the time.
After a few days, I received a response from one of their agents asking me
to use Safari.
I responded that I was blind; using JAWS as a screen reader, and that it was
literally impossible for me to use Safari on a Windows machine, because
there is no accessibility support.
We went back and forth a few times, and the agent kept saying that they
could not reproduce the issue with the registration form.
Finally, the last response I got was this: "We only test using Safari"
If anyone here is from Apple, they are welcome to verify the ticket, it was
submitted last September.

My point is this, it is not reliable, accurate, or consistent to rely on
only one browser and AT combination to conduct comprehensive and definitive
accessibility test results.

From: Patrick H. Lauke
Date: Fri, Sep 13 2013 1:32PM
Subject: Re: "for Chrome devs: intro to accessibility course"
← Previous message | Next message →

On 13/09/2013 18:10, Bryan Garaventa wrote:
> My point is this, it is not reliable, accurate, or consistent to rely on
> only one browser and AT combination to conduct comprehensive and definitive
> accessibility test results.

Of course, but is it really a surprise that a course offered for free by
Google focuses on the browser and (limited) AT by Google for testing?
Why are Freedom Scientific not providing guides on how to use NVDA or
Dolphin on their site?

My point is: instead of immediately slamming this effort as being "not
enough", "vendor-specific", "inaccurate", I'm actually seeing it as a
positive that an organisation with the developer mindshare that Google
has is even mentioning the topic (and I do believe that their materials
will cover accessibility and ARIA in general, then showing the results
in Chrome and ChromeVox, rather than being "how to make things work just
for ChromeVox"). And if even a few devs make the effort to work through
the material and make their sites more accessible (albeit only testing
in Chrome/ChromeVox), that's still preferable to those devs NOT doing
anything at all.

Sure, the course should be vendor-neutral, cover all disabilities,
etc...but then we may be looking at the wrong source for it.

Anyway, this counter-rant not aimed at anybody in particular...

P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Ryan E. Benson
Date: Sat, Sep 14 2013 2:48PM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Denis Boudreau wrote:
>But when I analyze the whole thing coldly, I think the perspective of
expanding the understanding of developers to view accessibility as a more
than just the blind over the next few years is still more interesting than
the perspective of continuing to talk about alt text to developers who've
never heard of accessibility.

A non-dev friend posted a link to to the course the other day, with "wow
this is so awesome", I pointed a short blurb about the issues, which were
covered at some point in this thread. Their reply was along the lines of
they know that there are probably other things to do or keep in mind, but
covering more areas would most likely result in too much information. I
hope Google holds another that covers other disabilities, however, to be
blunt, I doubt it.

--
Ryan E. Benson


On Thu, Sep 12, 2013 at 11:05 AM, Denis Boudreau < = EMAIL ADDRESS REMOVED = >wrote:

> Hey,
>
> I gotta say I agree with you Karl.
>
> I was one of those who complained about this as soon as I saw it (mea
> maxima culpa), and even though I was immediately thankful for Google for
> actually doing this (their reach is indeed far greater and that's
> ultimately a good thing for the field because more devs are going to hear
> about it), I was bothered - scratch that - pissed off by the fact that
> while we spend so much time and energy widening the scope to include other
> types of disabilities, all of a sudden, Google would come in with their big
> corporate resources and walk all over our efforts and narrow it down again.
> So that pissed me off, I have to admit.
>
> Then, as I discussed with people that are much wiser than I'll probably
> ever be (waving at you JF), I came to realize that Google can get a lot
> more traction than we ever will as individual cogs in the a11y wheel. So
> maybe they can succeed at drawing new people to the field, something we
> very much struggle to do on our own. So, a lot of positive can indeed come
> out of this.
>
> It's no coincidence that Google is offering this free training now - their
> goal is most probably to widen their userbase both in terms of developers
> relying on ChromeVox and end users actually trying it, and they want the
> best, positive corporate image they can have (who wouldn't).
>
> The context is changing and with all the legal and government requirements
> falling into place all over the world and especially in the US, there's
> certainly an interest in making sure developers that are going to have to
> learn about this accessibility stuff anyway actually learn about it the way
> Google wants them to learn it: using Chrome, ChromeVoX and relying on their
> developer tools. If I was investing in Chrome and wanted to reverse the
> shift in the screen reader userbase, this is exactly what I'd do too. What
> better way to bring more people to an emerging solution such as ChromeVox,
> as Jaws and Window-Eyes shares are being progressively divided between
> VoiceOVer and NVDA? Google wants a piece of it too. Can't blame them for
> that.
>
> Indeed, Google's tools and resources are awesome and indeed a lot (most?)
> developers use Chrome, so it makes perfect sense to offer them tools they
> can simply integrate to their current tool set. Indeed, they are very much
> oriented towards their own products and the gain they can get from the
> whole thing. This is a business after all, and we need to remember that the
> bottom line is what matters most. So, I've come to the conclusion that it
> doesn't matter so much how Google approaches it, as long as they do
> approach it. I believe we can trust them to say the right things after all.
> They'll probably put way too much emphasis on way-aria, might even
> diminish the importance of semantic markup in the process (love those
> checkbox roles on spans, right!), but it will expose more devs to our
> cause. And that's ultimately a good thing. But there's another potential
> problem looming.
>
> We all want more people to hear about accessibility, and if I had to
> choose, I'd rather spend the next 5 years of my life widening the
> understanding of developers who were in contact with this training to
> include other types of disabilities, rather than keep trying to raise
> awareness in order to bring new people to accessibility. But I do see a
> potential problem here. As more devs learn about a11y the Google way, there
> will be an even bigger push on more recent technologies such as wai-aria
> for instance. And that might result in a widening in the digital gap for
> end users who only have access to old version of assistive technology that
> don't support aria. That means that initially, some users who do not have a
> recent version of a screen reader will be left behind. Those will probably
> need to upgrade more than they'd want to, and there will be tools available
> to them for free. If some of them can't upgrade to the latest version of
> Jaws and decide to give ChromeVox a try, I don
> 't think anyone at Google will mind.
>
> But, the one thing that worries me here is that developers who lear about
> a11y the Google way are going to start building sites that are accessible
> to a screen reader used mostly by developers (Chromevox), while the real
> end users will still be using the other, more prominent screen readers with
> which those same developers will not have tested their content with (jaws,
> nvda, etc.). This means that the user experience of those who build will
> look good, while the user experience who those in the receiving end might
> be shakier... It would suck to come to a point where there's developer
> accessibility and end user accessibility. And that's very much a
> possibility, unless the devs trained with the Google tools actually widen
> their horizons by integrating other tools in their tool set.
>
> Whether we like it or not, this effort on Google's part will have a
> considerable impact on the work we do. Most of it good, some of it maybe
> not so much. As Google keeps its focus on visual disabilities, the rest of
> us will have to make sure we spend the next few years expanding the a11y
> horizons of the new folks Google trained in (the otherwise rather narrowed
> down field of) blind/screen reader accessibility.
>
> But when I analyze the whole thing coldly, I think the perspective of
> expanding the understanding of developers to view accessibility as a more
> than just the blind over the next few years is still more interesting than
> the perspective of continuing to talk about alt text to developers who've
> never heard of accessibility.
>
> So with a few caveats I have now come to think that this is indeed a good
> thing for our field and am grateful to Google for deciding to invest their
> resources into this. Nobody else could have done this. I can't help be
> worried of the impact, but it would be no different if any other vendor
> with interest in a marginal screen reader solution had done the same.
>
> While I agree that any vendor with an interest in accessibility would be
> biased in such a training offer, I still see a huge difference in terms of
> potential impact for end users when that vendor happens to develop a screen
> reader barely none of those end users are currently using. I don't think
> we'd face similar issues with SSB, HiSoft, Deque or IBM for instance.
>
> But I want to acknowledge the positive in all this and for that, I want to
> both apologize to Google for bitching about it in the first place and thank
> them for offering something that puts us on the path of a broader exposure
> for web accessibility.
>
> /Denis
>
>
>
>
>
>
> On 2013-09-12, at 9:39 AM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Not responding to anyone in particular so much as the general hoopla over
> > this course, especially considering nobody has actually seen it yet.
> >
> > That's not to say that people are wrong in voicing concern over the
> > description of the course indicating that it is Chrome-specific and aimed
> > at a11y for the blind & visually impaired. But let me ask this: Do you
> > think that Deque's courses aren't gonna discuss Worldspace or SSB's
> courses
> > aren't going to talk about AMP? HiSoftware wouldn't talk about
> Compliance
> > Sherriff? And actually, if you haven't tried Chrome's Dev Tools and the
> > accessibility testing capabilities it has, maybe you should.
> >
> > Additionally, let's step back and look at what this course could do.
> > First, I think everyone universally agrees that accessibility problems
> are
> > best avoided. How does that happen? By educating developers. "This
> free,
> > online course from Google's Accessibility team is targeted at devs and
> > others who work using Chrome." Google has an incredible reach in the
> > developer community. The Google Developers channel on YouTube has more
> than
> > 350,000 subscribers. I have no idea how many people take courses like
> this,
> > but I'm guessing that if they push it hard they can get a ton of
> sign-ups.
> > In other words, despite its assumed flaws, this course has the potential
> > to reach out and engage far more developers than anyone else.
> >
> > This community has a terrible habit of being hyper-judgmental of anything
> > that comes short of perfection. The damn course hasn't even been released
> > yet and the virtiol leveled at Google is already ridiculous. Here's an
> > alternate idea: maybe as a community, we should embrace Google for their
> > efforts and help them market the hell out of it. Then attend the course
> > yourselves and take note of things you want to see improved. Send your
> list
> > to TV Raman and then thank him for reaching out to developers to make the
> > web a better place for all.
> >
> >
> > On Wed, Sep 11, 2013 at 1:40 PM, Alastair Campbell < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> Birkir R. Gunnarsson wrote:
> >>
> >>> Just remember that Chrome Vox use, as reported by the latest WebAIM
> >>> screen reader survey, was less then .5%, Voiceover around 12%, NVDA
> >>> around 14% and Jaws still in the 50% range.
> >>
> >>
> >> Whilst completely agreeing with Olaf's comment about priorities (missing
> >> the wheels!), I think more people should notice how much VoiceOver on
> iOS
> >> is used these days.
> >>
> >> From the Webaim survey [1], VoiceOver on iOS is the second most used
> >> screenreader at around 42% of people who answered.
> >>
> >> I base that on 72% of people using a mobile screenreader, and of those
> >> 58.5% use iOS. Therefore 42% use VoiceOver on iOS.
> >>
> >> Now, it is not necessarily the primary screenreader by any means, and
> you
> >> could argue that people use apps more than the browser, but still, makes
> >> you think!
> >>
> >> I checked back on that stat after talking to several regular screen
> reader
> >> users who said things like "I don't bother opening the laptop much
> anymore,
> >> I just use my iPhone".
> >>
> >> It would be interesting to include VoiceOver/iOS as an option for
> "primary
> >> screen reader" next year.
> >>
> >> 1] http://webaim.org/projects/screenreadersurvey4/#mobile
> >>
> >> -Alastair
> >> > >> > >> > >>
> >
> >
> >
> > --
> >
> > Karl Groves
> > www.karlgroves.com
> > @karlgroves
> > http://www.linkedin.com/in/karlgroves
> > Phone: +1 410.541.6829
> > > > > > >
> > > >

From: Srinivasu Chakravarthula
Date: Sun, Sep 15 2013 1:06AM
Subject: Re: for Chrome devs: intro to accessibility course
← Previous message | Next message →

Thanks Olaf. I think we both are thinking slightly in similar lines. Please read my post at
http://srinivasu.org/blog/2013/09/accessibility-is-not-just-for-blind-agreed-but-we-dont-have-to-blame/ on this topic.
Regards,

Srinivasu
http://srinivasu.org Twitter: @csrinivasu
about.me/srinivasuc
Sent from my iPad

On Sep 11, 2013, at 3:59 PM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:

> My concern is the focus on "visual impairment + screen reader". This runs the risk of severely limiting the much needed increase of awareness among web developers. Tailoring a web site only to visually impaired users using screen readers can actually decrease the accessibility for others.
>
> From my point of view, at least one other mode of accessing content (beyond screen readers) **must** be explained (and forced upon people taking such a course).
>
> It would already be helpful to work with another variation of visual impairment - low vision. A typical type of AT here are substantial magnification of content and text customisation (where the default layout of the web page is left behind). By using such AT different types of issues can be unearthed.
>
> Regarding Chrome Vox: it has the huge advantage that it readily just works in a widely used browser on at least Mac and Windows. Yeah, its different from other screen readers. Yeah, strictly speaking it is not even a real screen reader, as once outside Chrome you are on your own again. But: once installed, a web developer can activate/inactivate any time with a keyboard short cut. It has visual highlighting, which takes it beyond NVDA. It is not as clumsy as VoiceOver on Mac OS X (which is a pain if you turn it on and off a couple of times). All ion all I would say Chrome Vox is just fine for use by web developers trying to find issues.
>
> So - main complaint from my side: at least one other type of AT (than screen reader) should be included (there are various readily available options for that! - for example, I find that NoSquint for FireFox is of extreme educational value for me).
>
>
> But let's not kill an initiative like this course - it's still better than nothing. Though it could probably be much more than what it seems to be today without too much additional effort...
>
>
> Olaf
>
>
> Am 11 Sep 2013 um 11:42 schrieb Alastair Campbell < = EMAIL ADDRESS REMOVED = >:
>
>> Jennison Asuncion wrote:
>>
>>> This free, online course from Google's Accessibility team is targeted at
>>> devs and others who work using Chrome. While the course is called
>>> Introduction to Web Accessibility, the specific focus is on blind/visually
>>> impaired users' accessibility. g.co/webaccessibility
>>
>>
>> Is anyone else uncomfortable with how user-agent specific the course
>> appears to be?
>>
>> It isn't just that it appears to reinforce the view that accessibility >> visual impairment, but also that ChromeVox appears to be the primary tool
>> for testing.
>>
>> It is especially troubling given Marco's excellent explanation of why
>> ChromeVox can interpret things differently, as it doesn't use the browser's
>> API:
>> http://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
>>
>> I'm almost inclined to tell developers and even accessibility testers *not*
>> to use ChromeVox as it the least used, and it is likely to work differently
>> from the ones that people do use.
>>
>> I'll hold criticism for the moment as the course materials are not up yet,
>> but alarm bells are ringing...
>>
>> -Alastair
>> >> >> >
> > >

From: Andrews, David B (DEED)
Date: Mon, Sep 16 2013 2:20PM
Subject: Re: "for Chrome devs: intro to accessibility course"
← Previous message | No next message

The larger issue here -- it seems to me is that Google is concentrating its accessibility efforts to solutions involving Chrome and ChromeVox. Not entirely, byut as we have seen from postings here in the past couple years, about Googledocs etc., they seem to primarily put their efforts into Chrome/ChromeVox efforts.

This doesn't bode well for support of other browsers, screen readers and/or other AT.

They can and should offer courses in their stuff, I don't think that is a problem. The bigger concern is what accessibility solutions will we get out of them in the future.

Dave



-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bryan Garaventa
Sent: Friday, September 13, 2013 12:11 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] "Re: for Chrome devs: intro to accessibility course"

Emotional responses aside, George does bring up valid points, and it's not a matter of condemning Google or anyone else for exploring efforts in accessibility.

The range of responses to this topic are sort of interesting, going from instant support without verification to, as you said, condemnation.

The first one seems to indicate that people are more likely to support what is most popular instead of what is most accessible; the bandwagon effect, and the second muddies the waters by focusing on a company rather than a solution.

The biggest problem here is the assertion that accessibility can be accurately determined using only one browser with one AT, and this is simply incorrect.

For example, a year ago, I discovered some ARIA bugs using an iPhone that I wished to report to Apple using their bug tracking system.
To do this, I needed to sign up for an account on their system, and as it turned out, it was literally impossible to do using IE, Firefox, or Chrome.
I tried to do it in all three, and every time the form would not submit properly, throwing an error.
I contacted support and opened a trouble ticket, providing precise steps to reproduce and including the browser and versions I was using at the time.
After a few days, I received a response from one of their agents asking me to use Safari.
I responded that I was blind; using JAWS as a screen reader, and that it was literally impossible for me to use Safari on a Windows machine, because there is no accessibility support.
We went back and forth a few times, and the agent kept saying that they could not reproduce the issue with the registration form.
Finally, the last response I got was this: "We only test using Safari"
If anyone here is from Apple, they are welcome to verify the ticket, it was submitted last September.

My point is this, it is not reliable, accurate, or consistent to rely on only one browser and AT combination to conduct comprehensive and definitive accessibility test results.



----- Original Message -----
From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Friday, September 13, 2013 12:41 AM
Subject: Re: [WebAIM] "Re: for Chrome devs: intro to accessibility course"


> On 13/09/2013 02:20, George Zamfir wrote:
>> So, what we are now saying is that maybe we should make a compromise and
>> accept this course as-is and hopefully it will turn out OK. Maybe this
>> "imperfect" (for lack of a better word) course is better than nothing and
>> maybe we're better off with more developers having limited knowledge of
>> accessibility (unknowingly limited) than what we have today.
>>
>> I do not think that this is a compromise worth making. Also, it sets a
>> dangerous precedent (more below).
>
> Ok, so we either have courses that are holistic and cover all areas of
> accessibility, all tools, all browsers...or nothing at all! Hmmm
>
>> I think we can all agree that this course introduces fragmentation - as
>> we
>> now have, let's say "Google accessibility", focused on blind /
>> screen-reader / ARIA, which is obviously a subset of accessibility. This
>> can only lead to more fragmentation (how about a "Microsoft
>> accessibility"
>> focused on motor / gestures, which is not far-fetched with the Kinect) or
>> a
>> monopoly ("Google accessibility" becomes THE accessibility non-official
>> standard). Whether further fragmentation or monopoly, maybe this is a
>> sign
>> of evolution for web accessibility and it's just one cycle that we're
>> seeing.
>
> That ship has already sailed. For better or worse, when you mention
> "accessibility" to a developer the first thing that comes to their mind
> is blind users with screenreaders, partly because that's the most
> technically demanding situation (and in many ways more deterministic and
> easy to grasp from a dev's point of view compared to, say, changes to
> actual content that need to be made for certain aspects of cognitive
> disabilities).
>
>
>> The difference today is ARIA, this is our "new ways of manipulating web
>> documents". It is crystal clear to me that we're on this trend of using
>> ARIA as our weapon to manipulate HTML. I've worked on various projects
>> with
>> respectable companies active in accessibility who completely disregarded
>> the HTML markup because "we'll fix it later with ARIA" or "yes, the
>> framework is not accessible but we'll use it anyway because ARIA". What's
>> surprising to me is seeing the same attitude among accessibility
>> professionals. Who cares whether we use a DIV or a BUTTON when ARIA can
>> change the role anyway? Especially as long as it is WCAG-conformant...
>
> There ARE situations outside of developer's control: clunky content
> management systems that don't allow for certain markup to be used; 3rd
> party frameworks and widgets that the devs can't modify; having to work
> with templates that have been mandated and cannot be altered; etc. In
> those situations, ARIA can be used to re-inject the correct semantics
> into inappropriate markup. But yes, devs will also abuse this tech, like
> they do any other tech.
>
> And it's not about WCAG-conformant, but results-driven: can users still
> get the meaning/functionality. Ultimately, that's what matters, rather
> than semantic purity.
>
>> We've stretched the use of ARIA (Accessible Rich Internet
>> Applications) from RIA (Rich Internet Applications) to damn buttons and
>> links, we've let this happen slowly but surely. ARIA used to be the
>> advanced topic, the stuff you use on those RIAs because there was no HTML
>> equivalent. Now ARIA is on page 1, semantic markup, WCAG & the HTML spec
>> footnotes.
>
> So we're bemoaning the fact that it's not an advanced, hidden topic
> anymore? Again, results-driven!
>
>> The dangerous precedent is that we're encouraging the use and teaching of
>> ARIA as THE web accessibility standard & solution. Google not only fully
>> endorses this ARIA direction (based on how all of their products are
>> built)
>> but will now teach it as being the de-facto web accessibility (of course
>> Google is not the only one). Yes, the full courses are not posted but the
>> first page of Unit 1 - Introduction mentions ARIA (Jared tweeted this:
>> "If
>> the first page references aria-labelledby and DOM references (and defines
>> neither), it is NOT an "introduction" to web a11y") and unit 3 is "Using
>> Live Regions". I think this is a pretty good indicator of the ARIA
>> direction.
>
> Perhaps, just perhaps, the examples they'll show will also fall under
> the category of dynamic, interactive experiences where those ARIA
> attributes are actually necessary. I somehow doubt that Google's course
> will go through lots of static page examples and will instead focus on
> AJAX-y web-app-like examples.
>
> Anyway, please all carry on condemning the Google initiative for its
> inaccuracies, as that seems to be what we as a community are good
> at...rather than seeing it as a positive step, we're quite happy to slam
> it for not being comprehensive enough.
>
> P
> --
> Patrick H. Lauke
> > re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
>
> www.splintered.co.uk | www.photographia.co.uk
> http://redux.deviantart.com | http://flickr.com/photos/redux/
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke