Accessibility support in the Toolkit

kirtid — Fri, 20 Apr 2007 08:33:00 GMT

Accessibility has long been one of the most neglected aspects in the software development process. Those who do take it up, do so because they wish to secure a customer who has government compliance clauses. Getting resources assigned for accessibility work is a tough job with few takers. We, the Toolkit team, think it is a fulfilling and worthy task and do not want to deprive users with disabilities of the Toolkit's coolness!

Although accessibility on the client has been pretty stable in terms of Assistive Technologies(AT) and platform support, web accessibility remains in its nascent stages with the web redefining itself. W3C is working on the WCAG 2.0 draft which will be the second attempt to flesh out web accessibility guidelines in the wake of the AJAX movement. Its charter is to deliver a web accessibility standard that will guide web developers to author semantically correct web sites which will communicate better with AT devices.

We eagerly await the industry standard that both web technologies and AT devices will comply with. However, till then the Toolkit controls need to be as accessible as possible to everyone, including users with disabilities within the current scope of accessibility guidelines. To achieve that goal we have an Accessibility Plan in place and hope to deliver support one issue at a time. We have already started making efforts to fix issues as we find them and we have a lot more in our Issue Tracker that we would like to take up soon.

So join us in your efforts to make the Toolkit more accessible. We are not Accessibility experts but working on it, so if you have accessibility domain knowledge, we see a potential partnership here! How can you help? Know about issues in Toolkit that could be changed to improve the accessibility experience, send us an email, post it on our forums or simply create a work item.

Some useful links:

Section 508 is the US Law that states that all software should not discriminate against users with disabilities by disallowing them access to features that normal users have and prevent them from making the best use to operate effectively.
European policies are also in place to ensure that the software is accessible to all.
Juicy Studios is a site which provides guidelines on authoring accessible websites
Learning the world is very good blog on web standards and accessibility

Toolkit for all!

Feature complete AutoComplete extender? Not yet.

kirtid — Fri, 30 Mar 2007 01:48:00 GMT

I just finished making a bunch of changes to the AutoComplete extender in the Toolkit. You can now css style the AutoComplete extender and make it as fancy as you would like it to be, well, as long as the completed content is text, which is what we support right now. But it is still pretty straightforward and meets most common scenarios. And hey, it is free! So you can download the source code at this very moment and start playing with it, even deploy it right away. These changes will be part of our official release within the next couple of months but there is nothing stopping you from using the latest bits. If you run into issues, please post them on our forum or report a bug.

The autocomplete flyout is a custom menu and we need to handle keyboard and mouse events explicitly. We also have one more task at hand which is making the extender accessible, which means that the menu html needs to be keyboard usable, use semantic html and be in the right dom order to start with. There is more to AJAX accessibility than that of course; as you delve deeper to add regular features which need to be implemented to meet core scenarios you will always discover that they need nasty workarounds to ensure accessibility and cross browser support. The browser as an application platform is not fun to work with given its eccentricities.

Anyways, back to the accessibility features...To achieve DOM order correctness, the autocomplete flyout element is now inserted right after the textbox; which means that it will be in the screen reader's list to read out loud next. The other issue is keyboard support, which was already present in the extender but needed to be tweaked to work with scrolling. In cases such as this one, it is most useful to operate as closely as existing menu controls to avoid any learning curve and introduce behavior that is not very intuitive which just means more work to be done in the extender itself. The keyboard support now handles scrolling which I compute based of the scrollHeight, scrollTop and clientHeight properties on the flyout element. I was attempting to use scrollIntoView to avoid performing the computations myself but it was based off the window and it resulted in the whole window scrolling when I hit the down/up arrows in the flyout. Bertrand Le Roy, a developer from the ASP.Net AJAX team and my accessibility cohort, recommended that I do it myself and that turned out to be the safest bet, worked across browsers and was under my control. The third thing was semantic html which was an almost easy fix, but one which will go a long way in making the autocomplete flyout useful for people with disabilities. The flyout markup is now an unordered list and that helps clarify the purpose of the element to the user. An additional accessibility feature came in as a freebie. I earned it by making the flyout css stylable, support in High Contrast mode. The color and background of the flyout can be friendlier in that scenario. Although, I have to admit that the colors I have chosen on the Toolkit sample website autocomplete menu will not work very well in high contrast. My reasoning? I was lazy to find colors that worked in normal mode in all browsers and that would work in high contrast as well.

What about localization? We already support localizing strings in the Toolkit but with css styling in, left-to-right and right-to-left settings are a piece of cake, chocolate cake perhaps...better and better!

So the AutoComplete extender supports theming as do all extenders in the Toolkit, is xhtml compliant, has international support, is almost accessible and very stylable. What's next?

Additional keys support like "home", "end", left/right arrows
Ability to pass additional data to the webservice; currently you can only pass the text in textbox and the number of suggestions you would like
Custom return types? Like pictures in the list? Wow, that would be nice but not on the radar right away...

Take a look at our bugs list to see if someone is already demanding for something you may be looking for as well.

Onto a "Feature Complete" AutoComplete extender!

Hello Kirti : Accessibility

Accessibility support in the Toolkit

Feature complete AutoComplete extender? Not yet.