WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Do people actually want Automatic Accessibility within Web Technologies?

for

From: John Foliot
Date: Apr 20, 2012 1:34PM

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