WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Do people actually want Automatic Accessibility withinWeb Technologies?

for

From: Bryan Garaventa
Date: Apr 20, 2012 2:54PM


I understand that all technologies are different, and all have their own
methodologies for making them work correctly, and not all of them will work
together as well as they should. However, everything has to start somewhere,
and there is value in establishing a reliable baseline.
For example there are accessibility APIs for Flash, Windows, iOS, and so on
at the platform level already which people already use for this purpose.

Since there are infinite ways to combine HTML/XHTML, JS, and CSS however,
this medium is far more challenging, since there are also infinite ways to
get them wrong.

What I'm hearing from these threads is basically, it's too big, it's
impossible, forget it.

What I know from experience however, is that it can be tackled by starting
in one place and moving onward, that it's definitely possible, and that it
shouldn't be forgotten.

The reason I know this, is because I already built an API that acts as a
baseline to make complex processes automatically accessible. I've been
working on it for three years now, and it works. It's called AccDC, and it
fully powers the dynamic website at
http://whatsock.com/

When I referred to fully encapsulated scalable and automatically accessible
user interface components, I was not speaking hypothetically. They are in
the download section, and they are as automatically accessible as it is
currently possible to be given recent advancements in browser/AT
combinations and ARIA.

Technology grows and we all have to adapt. This is also true for Assistive
Technology and platform combinations as well.

The first step for any true advancement is to establish a baseline from
which to work, otherwise there is nothing and we are going nowhere.



----- Original Message -----
From: "John Foliot" < <EMAIL REMOVED> >
To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
Sent: Friday, April 20, 2012 12:34 PM
Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
withinWeb Technologies?


> Bryan Garaventa wrote:
>>
>> Thanks, I agree, I'm not recommending another term, this is simply one I
>> use myself when I'm trying to explain the concept to others.
>
> LOL, then you *are* introducing a new term, at least to the "others" you
> are
> explaining to...
>
>
>> I've found that
>> most people who aren't familiar with programming or accessibility, have
>> no idea what universal and inclusive design is, and they find it
>> confusing.
>
> I'm not really sure what the net gain is from explaining one new term -
> Automatic Accessibility - versus explaining another new term - Universal
> Design - especially when at least the second term is more widely used. And
> I
> *really* have an issue with the notion of "automatic" - it smacks too much
> of "click this button and your accessibility woes will go away" - but
> maybe
> that's just me.
>
> If you *really* need a new term, I'd personally be way more comfortable
> with
> "Embedded Accessibility", which based on the balance of your response is
> equally true, but less "magical": we can embed systems and processes, that
> *when used correctly* facilitate accessibility without a lot of manual
> manipulation. This is absolutely true, and a laudable goal to pursue.
> (This
> is actually the truest definition of Universal Design - a design that
> facilitates accessibility when used properly)
>
>
>> I agree that heavy lifting is often necessary for the development of
>> truly
>> accessible applications, however it is possible to automate the
>> accessibility of baseline processes within a framework designed for that
>> purpose, so that new web technologies and current ones can tap into the
>> same functionality.
>
> Ah, OK, so something along the lines of "moving to a CMS, where most
> authors
> can't mess with the backend code, gets us greater gains in accessibility
> overall" - ya, I can agree to that. But it still means that I need to
> teach
> the content authors to not open the shiny new, accessibility friendly CMS,
> and type something like "click on the red button on the right".
>
> Or perhaps something along the lines of the Captioning System we developed
> when I was at Stanford, where the end user "fed in" their video, and we
> programmatically did some 'behind the curtain magic' and returned
> web-friendly videos PLUS time-stamped caption files, copy and paste code,
> and a Flash-based player that combined all the stuff we generated into a
> web
> page that then rendered closed-caption videos. The content creators had no
> idea what we were doing behind the scenes, but we established a work-flow
> that simply generated captioned videos as an end-state, which was the net
> win of the project.
>
>
>>
>> This provides a programmatic standard that can be used as a development
>> platform, a framework where encapsulated widgets can be created and
>> distributed as scalable automatically accessible user interface
>> components,
>> and a learning aid for the education of new developers at the same time.
>
> At a very high level, at the enterprise, this makes enormous sense, and in
> fact moving to these frameworks benefits more than just accessibility.
> However, moving to them allows us, as accessibility practitioners, to
> achieve gains at a much more scalable and high-level perspective than
> going
> after "Dreamweaver built" web-pages, which we all know is a thankless and
> never-ending task.
>
> JF
>
> > >