WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Andrews, David B (DEED)
Date: Sep 16, 2013 2:20PM

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 REMOVED> [mailto: <EMAIL 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 REMOVED> >
To: < <EMAIL 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