Fw: Regarding an accessible component archive for MooTools that is specifically programmed to be as accessible as possible for screen reader and keyboard only users.

Hi,
Just passing this along in case it's of interest.

The accessible component modules now normalize equally between jQuery, Dojo, and MooTools, and interface with the HTML, DOM manipulation, and related processes within each respective library/framework so that functionality and accessibility is the same no matter how they are rendered.

Also, I wanted to determine if it really mattered which library/framework was used to render a particular component, to see if it would be more accessible in one verses another. From my testing, it looks like the only real difference has to do with the Dojo HTML rendering process, where JAWS doesn't always recognize content changes when they occur. This issue in Dojo was easily corrected by forcing the DOM to refresh after content was written though. MooTools and jQuery work reliably for this however, and don't need similar adaptations. 

At any rate, the normalization modules between these three libraries/frameworks work reliably now. Please let me know if anything looks off and I'll be happy to fix it.

----- Original Message ----- 
From: Bryan Garaventa 
To: MooTools-Users 


Hi,
I wished to pass this on in case it's of interest. This is the project I've been working on recently that prompted my earlier questions.

Accessibility for disabled users is a critical component of interactive component design, and this is often extremely difficult to quantify and establish for dynamic web applications. Nevertheless, this will be an extremely important aspect of future development for all web technologies, and will have a significant business impact in coming years.

The AccDC Technical Style Guide and Coding Arena for MooTools will hopefully be of help to those interested in pursuing this, which is a free development resource that is specifically designed to be as accessible as possible for all disabled Assistive Technology users, including screen reader users, keyboard only users, and voice navigation software users. Ensuring full keyboard accessibility also makes it possible to ensure the highest level of accessibility for those with mobility impairments, such as quadriplegics using virtual keyboards.

For example, all of the following component types are supported with specific coding guidance for each within the AccDC TSG:

ARIA and Non-ARIA Accordions
ARIA and Non-ARIA Tabs
ARIA Date Pickers
ARIA Listboxes
ARIA Menus
ARIA Radio Buttons
ARIA Sliders
ARIA Toggles, Checkboxes, Links, and Buttons
ARIA Trees
Banners
Carousels, Slideshows, and Wizards
Drag and Drop
Footnotes
Inline Form Field Validation and Dynamic Help Tooltips
Modals
Popups
Progress Bars
Scrollable Divs
Tooltips
Web Chat and Dynamic Message Announcement

There are three parts to the project:
1) The AccDC API, which is a scalable, cross-browser and cross-platform compatible Dynamic Content Management System that automates the rendering of dynamic content to ensure accessibility for screen reader and keyboard only users.  
2) The accessible component modules as documented within the AccDC Technical Style Guide, which is designed to provide reliable and consistent interaction designs that are accessible to the highest percentage of people possible, and to establish a baseline for Functional Accessibility that can be utilized, built upon, studied, and tested against.  
3) AccDC Bootstrap, which is an HTML parser that renders advanced, accessible interactive controls using semantic HTML markup.  

The AccDC API for MooTools is a MooTools extension, and plugs directly into MooTools 1.4.5+>.

The project home page and design pattern library is located at:
http://whatsock.com/tsg/mootools
and the related GitHub project is located at
https://github.com/accdc/tsg-mootools

Sincerely,
Bryan Garaventa