WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Do people actually want Automatic AccessibilitywithinWeb Technologies?

for

From: Bryan Garaventa
Date: Apr 22, 2012 5:13PM

Hi,
I've been going back and forth with John Foliot off-list, and he had some
awesome questions that I wished to share. He's been pivotal in helping me to
frame and explain the concepts of AccDC in a more comprehensive manner,
which admittedly is not something I'm very good at at times. So thanks a
million John, you rock!
In addition to pasting the questions/answers below, I've already added these
to the FAQ section at
http://www.kickstarter.com/projects/bgaraventa/accdc-the-accelerated-dynamic-content-api?ref=email

Q/A

What do you mean by Automatic Accessibility? There can't be a magic
accessibility button, that's impossible.

No, you're absolutely right, there is no such thing as a magic button to
automate accessibility.

Simply put, AccDC is an accessibility API for the web, which can also be
used to build powerful dynamic applications using JavaScript.

The framework allows developers to build encapsulated user interface
components in such a way, that accessibility is built in and can be
redistributed with the components themselves, so that accessibility can
propagate across various web technologies simply by the study and use of
these components. This is why the encapsulated object model of AccDC is so
important.

Also, as the use and knowledge of such components becomes more widespread,
developers will pick up on the techniques and concepts that are used in the
construction of these components, and begin to build their own in the same
manner. This is why I'm trying to raise the funds to write the book, so that
I can outline these concepts in a clear and concise manner, so the
construction of such components will be as accessible as possible for
everyone.

Are you talking about 100% accessibility?

No, of course not, accessibility will never be a 100% proposition because of
the various technologies and disability types involved. However, we can
certainly raise the bar as high as possible, which will have a positive
impact on the lives of millions.

How close is this to a Mixin?

As defined at
http://en.wikipedia.org/wiki/Mixin

The answer is sort of similar, but not really.

The concept for a Mixin is basically like this,
you have object1, and object2 with extra stuff in it,
then you merge object2 into object1 so that now object1 has the extra stuff
as well.
The drawback to this concept, is that, if there are pre-existing
accessibility issues within object1 to begin with, those issues will still
exist even after object2 is merged into it.

AccDC is more of a wholesale solution, where an enclosed object is provided
as a plug-and-play component.
Here is a simple example, which I've already implemented before.

There is an AccDC Object declaration, which is a block of code that loads
automatically when AccDC starts up.
The ID for this AccDC Object is 'tooltip', and is designed to display an
accessible tooltip message that is automatically announced to screen reader
users when displayed.
So, after it loads into AccDC, it's ready to be used like so within a click
event handler:

// Set the triggering element so that the tooltip will appear next to it
visually.
$A.reg.tooltip.triggerObj = this;
// Set the tooltip text that will be displayed.
$A.reg.tooltip.source = 'You must enter a valid email address to continue
with registration.';
// Now open the tooltip.
$A.reg.tooltip.open();

And that's it. All of the other stuff like event handlers enabling keyboard
accessibility, automatic announcement for screen reader users, mouseOver and
mouseOut functionality and so on, are already built into the tooltip object;
so all you have to do to use it, is to plug the tooltip object into any
application using AccDC, set a few parameters and open it, and it just
works.

Plus, and this is really cool, you can change the nature of the object on
the fly as well, while preserving the same level of accessibility. For
example, take the tooltip example above, where you can do the following from
within a click handler as well:

// Set the triggering element so that the tooltip will appear next to it
visually.
$A.reg.tooltip.triggerObj = this;
// Change the autopositioning so that the message appears to the left of the
triggering element instead.
$A.reg.tooltip.autoPosition = 7;
// Change the class name to apply a different styling to the tooltip.
$A.reg.tooltip.className = 'decorated tooltip';
// Set the tooltip text that will be displayed.
$A.reg.tooltip.source = 'You must enter a valid email address to continue
with registration.';
// Now open the tooltip.
$A.reg.tooltip.open();

Or, you could even change the nature of the tooltip AccDC Object into a
popup like so from within the same click handler, by loading the desired
popup content from an external HTML file. This would also preserve the same
level of accessibility.

// Set the triggering element so that the tooltip will appear next to it
visually.
$A.reg.tooltip.triggerObj = this;
// Change the role of the object from a tooltip to that of a popup.
$A.reg.tooltip.role = 'Popup';
// Change the rendering mode from 0 to 1, which will pull content from an
external file.
$A.reg.tooltip.mode = 1;
// Set the external file path, and point to a particular message using its
ID attribute.
$A.reg.tooltip.source = 'files/popupList.html #message1';
// Now open the converted popup.
$A.reg.tooltip.open();

Plus you can use nested and linked AccDC Objects to build complex components
like tab controls, dialogs, dropdown menus, carousels, wizards, or any other
user interface component you can think of.

Is this like a Polyfill? Or like Modernizr?

As defined at
http://remysharp.com/2010/10/08/what-is-a-polyfill/
and
http://modernizr.com/

A polyfill does fit the analogy, but not in the same way as it's commonly
understood.

The purpose of a polyfill is to patch up browser inconsistencies. For
instance, say you can do something on IE but you can't do it the same way in
Firefox, so you use a polyfill solution to make it possible to use the same
script so that it works in both IE and Firefox at the same time. jQuery
works like this, where you can use the same jQuery commands to perform an
action that is equally compatible in both IE and Firefox.

AccDC does the same thing, so you can create component objects that render
successfully across browsers and platforms, such as in IE and Firefox,
Safari on the Mac and iOS devices, etc. So, in this way, it does offer the
same functionality as a conventional polyfill.

Modernizr is a more specific form of polyfill, where Modernizr can be used
to run cross-browser compatible processes, and is designed to be plugged
into other technologies for this purpose, which is awesome!

Think of it this way, a polyfill is designed to bridge the gaps between the
browsers and platforms so the same applications will work on all of those
systems equally well, but this doesn't include accessibility.

AccDC does both at the same time, so that content is rendered in a
consistently accessible manner that is cross-browser compatible. AccDC does
this by updating the Document Object Model in ways that are proven to be
most accessible for keyboard and screen reader users, and includes a
framework for adding additional accessibility related information to every
AccDC Object so that accessibility is an integral part of every component.

So basically, AccDC is a polyfill for accessibility.

Is the concept of AccDC more similar to Modernizr, or jQuery?

There are more similarities with the way that jQuery works, at least on the
backend. When I first wrote AccDC in 2009, it was a jQuery plugin. This
limited its versatility however, since it couldn't be directly integrated
into other systems that didn't also use jQuery, and I didn't want the system
to be reliant on a constantly changing system. So I rewrote all of the API
functionality to use cross-browser functions based on the X library at
cross-browser.com, and kept some of the other open source components like
the event handling system, and then I rewrote everything else and removed
all redundant processes to make AccDC work faster. This is why the AJAX
functionality is similar to that of jQuery's, though nothing else is.

Would integrating AccDC into a larger package also see expanded benefits?

Yes! You can plug AccDC into larger packages to enhance the functionality of
those software systems. For example, you can plug AccDC into frameworks or
libraries like YUI and jQuery, to enhance functionality.

This works because AccDC is a closed system, meaning that it won't conflict
with anything else that's running at the same time. Another framework can
then generate AccDC Objects and use them within their own framework on the
fly, or customized user interface components that utilize AccDC can be
created and redistributed. Then you can have the combined functionality of
the framework or library and AccDC at the same time.

Also, AccDC can be used by itself, so you don't have to include it within
any other framework for it to work, so it is very versatile.

----- Original Message -----
From: "Bryan Garaventa" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Friday, April 20, 2012 1:54 PM
Subject: Re: [WebAIM] Do people actually want Automatic
AccessibilitywithinWeb Technologies?


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