Fw: Regarding AccDC

2 views
Skip to first unread message

Bryan Garaventa

unread,
Apr 23, 2012, 11:54:37 AM4/23/12
to free...@googlegroups.com
In case it's of interest.
Best wishes,
Bryan

----- Original Message -----
From: "Bryan Garaventa" <bryan.g...@whatsock.com>
To: "WebAIM Discussion List" <webaim...@list.webaim.org>
Sent: Sunday, April 22, 2012 4:13 PM
Subject: Re: [WebAIM] Do people actually want Automatic
AccessibilitywithinWeb Technologies?


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

Reply all
Reply to author
Forward
0 new messages