WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: "for Chrome devs: intro to accessibility course"

for

From: George Zamfir
Date: Sep 12, 2013 7:20PM


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