WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Do people actually want Automatic AccessibilitywithinWeb Technologies?

for

From: Birkir R. Gunnarsson
Date: Apr 22, 2012 5:36PM

Bryan

You've been doing some awesome work for sure.
I suggest you put this in a separate new thread with a more
descriptive subject such as (my accessibility library, please consider
funding it" or something.
(though you may want to run that by the list admin of course).
I think, from looking at implementing ARIA controls from scratch this
weekend, that a library like this could make a huge difference for
accessibility. Creating an accessible tab control from scratch is not
a trivial task, not even for a JQuery programmer with eperience. It is
very doable, sure, but to write all the associated event and keyboard
handling and testing it is not something you can do in a few hours,
and adding accessibility for mainstream developers has to be as easy
as possible. Of course it supplements other very valuable efforts,
such as trying to get better accessibility built into JQuery
components, but having a readily available open source framework for
generating accessible AJAX controls without having to take care of all
the underlying details, will both promote accessibility and
consistency in things like keyboard navigation of custom widgets.
I will most certainly pledge to this myself, and I suggest, besides
posting it to this list in its own thread, posting it to any W3C
working groups or lists you may be aware of and do more aggressive
tweeting to get the word out and get discussions going.
Good luck.
-B

On 4/22/12, Bryan Garaventa < <EMAIL REMOVED> > wrote:
> 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
>>>
>>> >>> >>> >>
>> >> >> >
> > > >