The Accessibility of WAI-ARIA
Issue № 319

The Accessibility of WAI-ARIA

Web developers interested in accessibility issues often discuss WAI-ARIA, an upcoming W3C candidate recommendation aimed at making web applications more accessible to blind and visually impaired users. But, can we recommend WAI-ARIA without reservation?

Article Continues Below

The accessibility community has welcomed the development of WAI-ARIA. Clearly, there are many benefits for screen reader users. Previously, when webpages were dynamically updated, screen reader users were unaware that something had changed, or else were thrown back to the top of the page. Now, WAI-ARIA can inform the screen reader about dynamic changes. We can make complex custom widgets—such as pulldown menus, tabpanels, hierarchical trees, or sliders—accessible by mapping their elements to the roles, properties, and states defined in the standard and supported by the system’s accessibility API—provided that users have recent versions of browsers and screen readers that support the standard.

Many users, however, have no access to the latest and greatest technology. Therefore, accessibility testing is typically based on software that “users out there” are likely to encounter at the workplace.

A benchmark for accessibility testing#section2

This is why the German BITV-Test (BITV is the German federal regulation mandating accessible information technology) prescribes using a dated browser (currently Internet Explorer 7) that would typically be used in combination with a dated screen reader like JAWS 8 that does not yet support WAI-ARIA.

For practical reasons the BITV-Test does not involve tests with screen readers. However, its checkpoints consider the limitations of older assistive technologies. The test will lower the score for sites where authors rely on WAI-ARIA—for example, by implementing widgets in a way that makes them inaccessible for users of older screen readers such as JAWS 8.

The question remains: Should accessibility testing settle for an outdated combination of browser and assistive technology that does not yet support WAI-ARIA? Doesn’t this create a disincentive for web developers who embrace WAI-ARIA to turn the dynamic web applications that clients demand into something that may be equally usable by blind users?

We have to step back a little to answer this question. First, what do the Web Content Accessibility Guidelines (WCAG) 2.0 tell us regarding the accessibility support required by technologies like WAI-ARIA? Second, how well do today’s browsers and screen readers support WAI-ARIA? And finally, what are the practical obstacles to deploying WAI-ARIA at the workplace?

“Accessibility support” according to WCAG 2.0#section3

Simply put, “accessibility support” is a bridge with two arches. Only if both arches are present, can users of assistive technologies access all the information that is available to users without disabilities.

The first arch is the web technology used. Web designers sticking to the WAI-ARIA specification and recommended Authoring Practices can ensure that their content is potentially accessible.

Why “potentially?” Because we are still missing the second arch: Suitable user agents. Browsers and screen readers need to be redesigned or modified to be able to actually work with new web technologies. Older versions may simply fall flat.

So declaring “accessibility support” for a particular web technology is not simply a matter of finalizing the standard. We must also gauge the degree to which newer supporting user agents have penetrated a given context of use. The situation tends to vary considerably across counties, languages, and use environments. In a section on Understanding Accessibility Support, the WCAG working group and the W3C therefore

do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported


defer[s] the judgment of how much, how many, or which AT [assistive technology] must support a technology to the community and to entities closer to each situation.

While a company’s IT department may ensure accessibility support for its intranet, public websites provide information to a very diverse population using a wide range of user agents and assistive technologies.

That is why WCAG 2.0 clearly states:

Creating content that can’t be used by the general public with disabilities should be avoided.

If we accept this “general public” as our benchmark, we find that currently, there are still many obstacles to the widespread use of WAI-ARIA.

WAI-ARIA support in browsers and assistive technologies#section4

Support for some parts of WAI-ARIA, such as document landmarks, is already quite good in later versions of browser and screen readers. However, many problems remain.

Uneven level of support across assistive technologies#section5

WAI-ARIA support is still patchy in many screen reader/browser combinations out there, see, for example, the (slightly dated) WAI-ARIA tests on code talks. The sheer number of makes and versions of browsers and assistive technologies makes it hard to gauge the given level of support. And providing workarounds for some known screen reader bugs can make life harder for users of other, more compliant browsers and screen readers.

Blind users without WAI-ARIA support may simply not recognize a web widget if its WAI-ARIA role is not exposed. Take a tab panel implemented according to WAI-ARIA best practices. The screen reader will not tell users that they have just entered a tab panel and can now use the arrow keys to move between tabs. So users are likely to tab on beyond the tab panel’s content. And the scripted focus changes for arrow key navigation between tabs may just not work: entire sections under tabs can become inaccessible.

Let’s not forget visually impaired users. The current versions of popular screen magnifiers have no WAI-ARIA support. ZoomText is apparently not even aware that WAI-ARIA exists. Freedom Scientific plans partial support in MAGic in the next version (the current version is 11.0). Dolphin expects support in HAL and Supernova starting with version 12.5.

Correct and incorrect uses of WAI-ARIA#section6

Currently many implementations do not conform to WAI ARIA best practices to ensure that they work as intended. WAI-ARIA coding errors can actually deteriorate widget accessibility. What contributes to the coding complexity is that the native semantics of HTML elements can be in conflict with the semantics added through WAI-ARIA roles.

The interaction of these problems means that designing with WAI-ARIA can be tricky. Web developers therefore increasingly use screen reader tests to ensure that designs work correctly across a range of assistive technologies (for a start, the NVDA screen reader is free and easy to install).

Implications of widgets for sighted keyboard users#section7

WAI-ARIA’s main benefits are for blind users. For them, desktop-style widgets on a webpage need no longer be inaccessible. But the proliferation of such widgets also has implications for sighted keyboard users.

In contrast to desktop widgets and their conventions, the self-styled widgets on the web come in many flavors. Those that conform to WAI-ARIA best practices are few and far between. What, if any, keyboard interaction a particular widget actually affords is therefore down to guesswork.

Again, take tab panels. There is no easy way to distinguish between a common tab-style main navigation bar and a widget with a tab panel navigation further down the page. And only few tab panels out there afford arrow key navigation instead of tabbing. Sighted keyboard users will have to try out what keys will work. (For blind people using WAI-ARIA capable screen readers, this is actually less of a problem if widget roles are announced in the same way as desktop widgets.)

Another critical point is that custom widgets depend on stylesheets to position their elements. Without CSS or seen with custom stylesheets, these widgets disintegrate and are no longer usable. Widget elements may appear twice or far removed from the intended position. And background images assigned with CSS will disappear (the same happens when using custom color schemes).

Obstacles to using WAI-ARIA in the workplace#section8

There is quite a different set of problems evident in the workplace. Often enough, the problems are outside of the user’s influence:

  • Many organizations deploy internet applications customized for a particular browser/screen reader combination. Customization costs are often many times higher than screen reader license or update costs. Known security holes (as in Internet Explorer 7) can necessitate upgrades, but this argument may not suffice if applications are (or ought to be) used exclusively on an intranet.
  • Many organizations still use old operating systems such as Windows 2000 which do not accommodate later browser versions such as IE8, and in turn, later screen reader versions. For applications and assistive technology that support rote procedures, there is no real incentive to upgrade unless workflow or major system upgrades demand it.
  • Many blind computer users working with WAI-ARIA-capable screen readers such as JAWS 9 or later, are not yet aware of—or trained to take advantage of—its full potential.
  • While NVDA and JAWS are currently most capable of dealing with WAI-ARIA, we must not forget users of other, less-capable screen readers.

Often, script-based customization for assistive technologies in the workplace tackles exactly those custom controls that WAI-ARIA could make accessible. Better support for WAI-ARIA may save much time and cost. This, however, presupposes that in creating web or intranet applications, developers use WAI-ARIA consistently and according to best practices.

Who’s without access to WAI-ARIA-capable screen readers?#section9

While we were researching this article, we took a quick sample of one large public German employer. Of the 15 workplaces for blind users we covered, not a single one currently supports WAI-ARIA:

  • Seven workplaces use HAL/Lunar (between Version 6 and 10),
  • Four workplaces use JAWS 6, and
  • Four workplaces use Blindows (between Version 2 and 4).

Of course, the situation may be better at other workplaces. Nevertheless, the sample indicates that a large, possibly very large, share of blind people at the workplace currently have no access to user agents supporting WAI-ARIA.

Survey and usage statistics#section10

Unfortunately, there are no statistics that can reliably quantify how many users have WAI-ARIA-capable screen readers. According to the WebAIM screen reader survey (October 2009), 83.6% of users update their screen reader within one year after the release of a new version. Focusing just on JAWS for a moment and considering the multiple JAWS releases after the first version with WAI-ARIA support in November 2007, the percentage of users still using JAWS 8 should have fallen well below 5%. However, the survey reflects the American market, which will differ from the situation in Germany. Also, it is likely that a high percentage of screen reader users responding to the survey were expert users and therefore, likely early adopters. We can assume that the average update rate across all users is much lower.

Unproblematic ways of using WAI-ARIA#section11

Many applications of WAI-ARIA aim to enrich HTML to rectify some of its semantic deficits. Since HTML 4 knows no explicit elements for marking up page regions, the WAI-ARIA spec offers so-called document landmarks. For example, we can mark up a simple div with role=“navigation” and expose the main page content with role=“main”. This allows screen reader users that support WAI-ARIA to move quickly between the different page regions.

Other attributes improve form markup: For example, we can give an input element the attribute aria-required=“true” to tell screen reader users that the field requires an entry before the form can be sent. ARIA live regions are another useful construct that inform screen reader users about dynamic changes to the page without losing the current keyboard focus.

Pages semantically enriched through WAI-ARIA do not currently validate, but this drawback is acceptable: Common browsers do not mind the additional markup. (The BITV test’s code validation step maintains an exception for validation errors caused by WAI-ARIA markup.) Sooner or later, when the working draft becomes a recommendation and the W3C validator has been updated, that problem will disappear (in HTML5, WAI-ARIA validates). Some sites currently circumvent the validation problem by adding WAI-ARIA attributes to the source code via a script that is executed when the page loads.

More problematic: custom widgets#section12

The WAI-ARIA specification supports a range of custom interface control widgets commonly used in desktop applications so that authors can use them in web-based applications (a full list is contained in the WAI-ARIA Roles Model).

Extensions of standard elements#section13

Authors often aim to extend the behavior of standard elements—for example, to create a tri-state checkbox or a select element that can also accept text input (the combobox). To achieve this, the known HTML elements are recreated by repurposing non-semantic elements such as a div or img, (replacing these as required via scripting to reflect different states), while using WAI-ARIA to inform assistive technology about the intended roles and states.

Self-styled custom widgets#section14

Then there are custom widgets that web designers have built for some time—widgets that WAI-ARIA should now make accessible, including pulldown menus, tabpanels, hierarchical trees, sliders, spinbuttons, and even drag-and-drop interfaces. The desired widget keyboard behavior is not provided like the default behavior of normal focusable HTML elements: It has to be explicitly defined through JavaScript. This constitutes the first problem, since for many custom widgets, there is no standard behavior in response to keyboard input. What works and what doesn’t has to be established empirically by the user.

WAI-ARIA’s lack of robustness is another problem: Its implementation in browsers and assistive technology is not that stable yet. Tricks are sometimes needed to ensure that widgets work as intended, as in a small scripted delay that ensures that elements added to the DOM tree can actually be focused by scripts.

Fallback options for users without WAI-ARIA support?#section15

Is it not possible then, to provide fallback options for user agents that do not support WAI-ARIA? In its coverage of the role presentation, the WAI-ARIA Roles document mentions that it “may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.”

Looking around, practical examples of such fallback solutions are conspicuously absent. It is hard to think of any useful application. Consider a custom checkbox with a native checkbox as a fallback option for screen reader users without WAI-ARIA support: moved off-screen via CSS to hide it for sighted users, and marked with role=“presentation” to hide it for WAI-ARIA-capable browsers.

But does it work? The role presentation suppresses WAI-ARIA attributes (apart from global attributes), but still exposes focusable elements like checkboxes. The WAI-ARIA 1.0 User Agent Implementation Guide states clearly:

…the element must still be exposed if it (…) is focusable, so that focus events can be fired (focus must never be lost)

Therefore, for screen reader users without WAI-ARIA support but with JavaScript on, the custom checkbox would receive focus, but not reveal its role and state. For screen reader users with WAI-ARIA support, the unnecessary fallback checkbox would not announce its role, but would still be in the tab order, be selectable, and change its state after selection. Finally, sighted users would be able to use the custom checkbox, but possibly also tab to and activate a hidden checkbox without any visual feedback. This clearly makes no sense.

WAI-ARIA in JavaScript UI libraries#section16

Many designers drawing on JavaScript functionality provided by popular JavaScript UI libraries will implicitly implement WAI-ARIA, as these libraries are adding support to their widgets and components. The situation is diverse. Dojo is said to offer mature WAI-ARIA support, YUI offers ARIA plugins for a range of widgets, and JQuery is expected to support WAI-ARIA fully in its 2.0 release. Other libraries, however, have no or only very limited support.

The inclusion of WAI-ARIA in JavaScript UI libraries is a good thing since it can be expected that here WAI-ARIA will be implemented according to best practices. However, the fact remains that on the level of hard- and software currently in use, accessibility support for WAI-ARIA cannot be taken for granted.


Appropriate semantic HTML elements, when available, are preferable to using custom widgets made accessible via JavaScript and WAI-ARIA. The difficulty of styling native elements reliably in CSS may appear to be a real pain for web designers: on the plus side for users, interface elements will be more recognizable and predictable when they simply look and work like the known system elements.

Designers should check whether complex custom widgets can be replaced by simpler native elements. Is it really necessary to use a combobox for an autocomplete function? Is it really unavoidable to have a tri-state checkbox? Can radio buttons with discrete values replace a slider?

This is not a call for interface design austerity. There is little harm in using fancy controls if they are given an equivalent accessible alternative. Take, for example, a slider that mouse users can move to set the amount they want to donate to SOS-Kinderdorf, a well-known charitable organization. Check out the second step of the SOS-Kinderdorf donation process (Design by Aperto AG). Depending on the amount specified, a little girl to the right expresses her gratitude in moderate to glowing terms (in German). Apparently, generosity has shot up sharply after the introduction of the slider, which should be sufficient proof of its utility.

While it would have been possible to make the slider work for screen reader users with WAI-ARIA support, the designers preferred a simple text input for the amount donated as an alternative: The tab focus order simply skips the slider. Importantly, the child’s reaction in the speech bubble is triggered by both types of input.

Let’s sum up. It is quite clear that JavaScript has become ubiquitous, and that WAI-ARIA is a welcome solution to address the accessibility gap that this development has created. Developers using WAI-ARIA today can help weed out implementation bugs in browsers and assistive technology. At the same time, they can contribute to best practice examples that can be used by many others as a blueprint.

But as long as older screen reader/browser combinations incapable of interpreting WAI-ARIA still constitute a significant part of the installed base, web designers who care for accessibility should use WAI-ARIA markup only to enrich their sites. They should not rely on it.


For hints and comments, many thanks to Carsten Albrecht, Alexander Farkas, Michael GroŸe-Drenkpohl, Jan-Eric Hellbusch, Werner Hoog, Martin Kliehm, Werner KrauŸe, Oliver Nadig, Hans-Herbert Suhling, Timo Wirth, Tiffany Wyatt and Marco Zehe.

Useful resources#section19

About the Author

Detlev Fischer

Detlev Fischer leads the development of the BITV test, a tool sponsored by the German Government and widely used to evaluate the accessibility of websites (follow bitvtest on Twitter). His stuff unrelated to accessibility can be found at

11 Reader Comments

  1. “But as long as older screen reader/browser combinations incapable of interpreting WAI-ARIA still constitute a significant part of the installed base, web designers who care for accessibility should use WAI-ARIA markup only to enrich their sites. They should not rely on it”

    This is an absolutely ridiculous statement. If you follow this logic nobody should write to HTML 5. There is not a single AT out there that supports the full features of HTML 5. It also makes a statement that companies should not try to invest in accessibility. For example, this statement argues that a major company like IBM should not invest in fixing things like JavaScript accessibility as the ATVs and users are not upgrading their work or tools.

    The bottom line is new government requirements will demand ARIA support to meet WCAG 2 compliance for most web applications. Otherwise, they will be simply inaccessible.

    So, as the industry converges on rich web applications ATs will need to add HTML 5 and ARIA support and users will need to upgrade. At IBM we have hundreds of products now integrating ARIA support and we are looking to HTML 5 – especially for mobile. This will require advanced browsers and advanced ATs and we are seeing our customers make the investment in these new solutions.

    This article’s argument implies that authors should write to HTML 4.01 and static content because ATs and AT users will not upgrade to support HTML 5 (which includes ARIA) or HTML 4 plus ARIA.

  2. Although I think most of your points are fair, I do tend to agree with Rich that both articles tend to lean towards the fear/unrest/doubt side of the spectrum. Is it really a surprise that implementations have bugs when the spec isn’t even finalized? Please continue to encourage authors to both 1) use ARIA, and 2) report any bugs to the browser and assistive technology vendors. The more web developers report bugs, the faster those bugs get fixed.

    Also keep in mind that ARIA is primarily meant to solve accessibility problems for web apps (the ‘RIA’ in ARIA) that previously had no way to be made accessible. For example, a spread sheet app or an Ajax-powered web mail application. Although backwards compatibility is a concern, most of the problems it’s solving don’t have any accessible solution, so that issue is not as prevalent in the RIA space. WAI-ARIA is essentially in the process of defining *the* accessibility API for the Web.

    As for the robustness issue you mentioned, have you seen our ARIA proposal for User Interface Independence? I’d be interested to hear your thoughts on it. “”:

    One final comment on your ‘two arches’ idea. Don’t forget that the third arch is an ARIA-aware assistive technology. Accessibility requires a web application, user agent (browser), and assistive technology (e.g. screen reader) to all work in harmony. While most web developers are not used to the broad range of combinations that entails, it’s not an insurmountable task. It’s a big task, but we’ll get there. Remember that, when this site (ALA) launched, all web developers were using tables for layout due to inconsistencies in the CSS support. Someday these ARIA inconsistencies will also be a relic of the past. Cheers.

  3. Jared Smith eloquently cut to the core of the point I was trying to make.

    bq. Developers will continue to innovate with or without accessibility. Because not building it is not an option and because some things cannot be made accessible without ARIA, *developers are left with two options — build it potentially accessible with ARIA or build it perpetually inaccessible without ARIA*.

    “The Ghosts of ARIA Present and Future”: on WebAIM.

  4. @ My conclusion should not be read to imply that developers should not use HTML5 or ARIA. The site “”: from which I took the (non-ARIA) slider example is actually an interesting case since it uses HTML5 *and* WAI-ARIA *and* goes a long way to ensure that content is also accessible with older assistive technology lacking WAI-ARIA support (it also works — sort of -with JavaScript turned off).
    Our point is rather that *if* developers use ARIA, they should be well aware of the limitations that currently exist. From a user perspective I would add that they should aim for simplicity and clarity and the use of native elements wherever possible. (And if they use the front page as a stage for layers upon layers of content — as on the sos-kinderdorf site – then they’ll have a hell of a job to make all that accessible!)
    I guess that most people frequenting this site agree that making things as simple and as elegant as possible is a worthy goal. The trend towards mobile user agents will help – take Luke Wroblewsky’s take on “designing for mobile first”: We think this is the right approach because it rids sites of unnecessary complexity.
    Currently, however, we can witness the opposite trend in web design: developers rush to implement all manner of fancy widgets and custom controls. Mostly proceed without making their stuff accessible — often not even on the level of properly managing focus order, let alone by adding WAI-ARIA. So there we see a risk that developers will just slap on some WAI-ARIA without proper testing and then claim they have created accessible applications.
    I think what does come out clearly from both articles in this ALA double issue is that currently, diligent testing with AT is needed to ensure that WAI-ARIA enabled widgets actually work across a range of commonly used technologies out there.

  5. @James Craig: I take your point that

    ??ARIA is primarily meant to solve accessibility problems for web apps (the “˜RIA’ in ARIA) that previously had no way to be made accessible??

    Using WAI-ARIA diligently and reporting bugs to improve it is the right way to go for web application developers. (And, for the time being, providing a working alternative for users without ARIA-support, at least for crucial services and information that must be available for everyone.)

    Thanks for pointing to the “User Interface Independence for ARIA” W3C proposal. I understand your reservations about the DHTML Style Guide WG keyboard shortcuts. I think the mechanisms you propose are quite elegant: they place the burden on the web app to pick up common user input in a user interface- and platform-independent manner, and to act on these events sensibly. If implemented widely that would remove some of the headaches regarding the predictability of interaction (consequences) that users encounter in web apps.

    In my arches metaphor, I took the second arch to to stand for the ensemble of UA and AT, but I agree that three arches would have been better.

  6. Thank you for a thorough summary. Accessibility seems to have been slipping off the agenda in the wake of ajaxy excitement. As a UX designer, I love the improvements HTML5 etc. bring to the user experience. But surely tech advances should be made from an inclusive standpoint first. (Think how much harder life is for some disabled users now everything is touch-screen oriented for example. Even as a left-hander with the slight shakes life is getting a little frustrating!)

    To be honest, I’ve found it hard to get to grips with the issues and this article has summed the up nicely, putting me and others in a better position to address the challenges and innovate *safely*.

  7. Detlev, thanks for posting a great article. Your article sets an interesting tone about semantics and equivalence. From your post, it seems that to some extent ARIA will be easy to implement, practical and effective to attaining equivalence. However, when we extend it to rich internet applications where incremental changes occur relative to a control, we may take functionality away from screen reader users especially when live regions come into play. I wish we could predict how users would cruise around using ARIA, 10 years from now. It will be interesting to see how users will create additional mental maps to capture dynamic changes on the page using ARIA.
    Regarding the sampled users in your article, can we assume that screen reader users in general do not really care about ARIA? Moreover, even if they would want to embrace it, would there be a learning curve? Especially, when we consider how sighted non-disabled power users will want to leverage the advancements made in this space to their advantage. However, the variables (browser vs. AT versions, browser vs. AT vendors etc.) are enough to make us rethink and ask ourselves a key question. Why are organizations not including accessibility reviews of their designs? I know some have made it mandatory to get a compliance certificate before an application goes live but it is not enough. It should be made mandatory to have a design that is inclusive of most, if not all, user groups.

  8. @ Devarshi: You ask whether blind users care about ARIA. If you start asking around in the community, you are more likely to get answers from users that are informed. Some actively promote ARIA, others emphasize that ARIA support is not yet widespread enough to rely on it.
    In any case, informed users realize that without ARIA, many of the dynamic bells and whistles that modern web sites carry (like it or not) will remain inaccessible.
    Blind users not interested in technical stuff are often not aware of ARIA (compare “WebAim’s Screen Reader User Survey Results”: where about 40% said they did not know that ARIA landmarks existed) . But then, they wouldn’t need to be – provided they have UA and assistive technologies that support WAI-ARIA, they will benefit when widgets are properly exposed.
    Whatever view you take on ARIA: the ability to use it to make widgets accessible to (many) screen reader users should not be taken as an invitation to make an interface more complex than it needs to be.

  9. The problem with the recommendations and discussion is that it relies too much on the developers and testers, and not enough on policy makers (gov and company). Detlev, your statement: “I think what does come out clearly from both articles in this ALA double issue is that currently, diligent testing with AT is needed to ensure that WAI-ARIA enabled widgets actually work across a range of commonly used technologies out there.” is too “currently” focused and seems to but all the burden on the developers. Where is the recommendation that policy makers promote, fund, and facilitate upgrades to AT, browsers, and other user agents that support all this accessibility investment? I agree developers need to be wise in adopting new UI paradigms and keep things simple, but many of us have enjoyed the rich accessible UI widgets from Windows and other desktop platforms that need to be made available in the web browser, and as mentioned – perhaps more importantly the rapidly emerging mobile smart phone platforms/apps. We all have to have a balanced view to the future, with policy makers (gov and company) and users picking up their part of the responsibility too along with the developers and testers. As the W3C WAI correctly focuses, there are ALSO standards for “User Agents” and “Authoring Tools” too – its not all “Web Content” that has the responsibility. All the stakeholders (technical standards, content developers, platform developers, testers/tools, user agent developers, AT developers, end users AND policy makers) ALL have a part in this journey – if we work EFFICIENTLY together, we’ll get there faster, with better accessibility.

  10. Often what I call “dumb policies” that prevent users at companies and government agencies from upgrading to newer browsers and AT – are just that – dumb policies. Screen readers users and other AT users already have unique configurations, and should be allowed, in fact encouraged and supported to upgrade to later browsers and AT so that the burden to test and support older inefficient and inaccessible technology is removed or at least reduced. Governments and public policy has a role too in areas where AT or support is not available yet in a native language – they should more wisely support the lower investment in AT than to require the higher costs in providing duplicate or dumbed down interfaces. We had this debate when moving from command line interfaces to graphical user interfaces (e.g. DOS to Windows), we had it when moving from static HTML to e-commerce, and we’re having it yet again moving to RIA and HTML 5. Persons with disabilities deserve access to the front door like everyone else. Lets educate the policy makers that there are smarter investments and trade offs.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA