WebAIM - Web Accessibility In Mind

E-mail List Archives

Regarding AccDC

for

From: Bryan Garaventa
Date: Apr 22, 2012 8:34PM

Thanks, I really appreciate that :) I'll try to do my best as always.

It's funny you mentioned tabs, they are actually one of the easiest control
types to make using AccDC.

Here's one way to do it.

Say you have an html file named Home.html, and the following three links are
included:

<a class="tab page1">Tab Page 1</a>
<a class="tab page2">Tab Page 2</a>
<a class="tab page3">Tab Page 3</a>

Plus a container tag like so.

<div id="tabContent"></div>

Now, in another file on your server at
files/tabs.html
you include the html syntax like so:

<html><body>
<div id="tabContent1">
Here is my content for tab 1.
</div>
<div id="tabContent2">
Here is my content for tab 2.
</div>
<div id="tabContent3">
Here is my content for tab 3.
</div>
</body></html>

Then in your JS file, you have the following code:

// Instantiate an array of AccDC Objects
$A([
// Obj1
{
// A unique ID for the object
id: 'tab1',
// A descriptive role
role: 'Settings Tab',
// Open this tab first when the page loads
autoStart: true,
// Specify the triggering element, an A tag with both classes 'tab' and
'page1'
trigger: 'a.tab.page1',
// Point to the file containing the tabs, and the ID attribute of the
correct tab container
source: 'files/tabs.html #tabContent1',
// Run optional script after loading completes to setup additional handlers
and stuff
runAfter: function(dc){
// 'dc' is the current AccDC Object instance ('this' in other words)
// e.g. dc.role will return 'Settings Tab'
}
},
// Obj2
{
id: 'tab2',
role: 'Help Tab',
trigger: 'a.tab.page2',
source: 'files/tabs.html #tabContent2',
},
// Obj3
{
id: 'tab3',
role: 'About Tab',
trigger: 'a.tab.page3',
source: 'files/tabs.html #tabContent3',
}
], {
// Now set shared parameters to be merged with all above AccDC Objects
// Set the triggering element event handler
bind: 'click',
// Set the container where tab content will be loaded into
isStatic: '#tabContent',
// Declare that all above objects are tab controls
isTab: true,
// Set the rendering mode to 1 so that content will be loaded from an
external file.
mode: 1,
// Prevent the tab from being closed by screen reader users via a hidden
close link
showHiddenClose: false,
// Set forceFocus to true to move keyboard focus to the beginning of new
content when loaded,
// or false to leave focus on the triggering element.
forceFocus: true,
}, true);
// The true parameter in the last argument sets AccDC to wait until the page
fully loads before registering all of these objects.

So this will
1) register all of the click event handlers for the triggering elements,
2) add hidden role and state information into each triggering link to
indicate the role of 'Tab' and 'Selected' when a tab is open for screen
reader users (which can be changed programmatically for location as
desired),
3) add an href attribute to all of the triggering links to ensure keyboard
accessibility (since it's missing on purpose),
4) load content into the page from each tab when the triggering element is
clicked, and
5) set focus appropriately based on the desired setting.

This is just a simple example using external files. You could do the same
thing using hidden tab content within the same file (Home.html), by doing
the following:

Say you have three hidden tags at the bottom of the file Home.html like so:

<div class="hidden tabContent1">
Here is my content for tab 1.
</div>
<div class="hidden tabContent2">
Here is my content for tab 2.
</div>
<div class="hidden tabContent3">
Here is my content for tab 3.
</div>

Then you just change the 'mode' parameter from 1 to 0, and
then change the 'source' parameter like so for each AccDC Object
declaration:
// For tab1
source: 'div.hidden.tabContent1 > *',
// For tab2
source: 'div.hidden.tabContent2 > *',
// For tab3
source: 'div.hidden.tabContent3 > *',

And that's it. You will then have inline tab controls either way, both
equally accessible.
Plus you can add inline scripting as well, within the tab source code or
within the AccDC Object using flow control, but the choice is yours.

It gets easier when you wrap your brain around the object model.

What's really cool, is that you can dynamically create these objects at
runtime, so you can create tab controls like this without having to have any
hard coded tags at all in the source code by using Core DOM Manipulation .


----- Original Message -----
From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Sunday, April 22, 2012 4:36 PM
Subject: Re: [WebAIM] Do people actually want
AutomaticAccessibilitywithinWeb Technologies?


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