WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Patrick H. Lauke
Date: Sep 13, 2013 1:41AM

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