WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: for Chrome devs: intro to accessibility course

for

From: George Zamfir
Date: Sep 11, 2013 12:13PM

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 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!
"