Child pages
  • Widget Accessibility
Skip to end of metadata
Go to start of metadata


This is written by someone learning about the issues surrounding accessibility, and not an expert.

Web User Interfaces and Accessibility.

This is not an expert view of accessibility, for that you should visit Fluid. This is more a record of discovery and learning about accessibility issues for the work on MySakai and Widgets. If you see anything that is incorrect or inaccurate in this page, please comment and/or correct.

For the purpose of this page a Widget is a Gadget that you might place in the portal, however the term is frequently shared (even on this page), with a small component that is created to add additional functionality to the page or form (eg a slider bar)



Web Accessibility covers may aspects of user interaction ranging from keyboard navigation to an assisted experience such as a screen reader. How the interface interacts and behaves is down to the way in which it is created and how it interacts with the web browser. If, during the creation of the interface, it is not designed to be accessible and also tested, it will not be accessible. In education we have a legal requirement to produce accessible interfaces in 508C and a similar but not identical regulation in Europe. There may be other regulations in other regions. It would be a dangerous mistake to assume that just complying with these requirements made an application accessible enough. We have to strive to exceed these requirements, almost but not quite to the extreme of ignoring them.

The "what does the law say?" Dilemma

Many are tempted to ask: What is the minimum we need to do to ensure legal compliance? This is not a good question to ask, because (a) it depends on when and where the question is asked - US requirements may be different to European requirements and the law in 2009 may be different to the law in 2008 and (b) there may be things that can be done to massively improved accessibility at low cost, but which are not currently legally required - if this is the case (low cost, high benefit) why would we not want to do them? Focus on legal requirements may mean we miss such opportunities. Focus on today's requirements could mean a constant race to keep up, if we aim past current requirements we may have a more comfortable life (as well as feeling good about ourselves).

On the other hand, if we avoid discussing legal requirements we may have some brilliant accessibility features, but fail to meet some minor legal requirement that means our fantastically accessible application cannot be labeled as accessible and we cannot bid for government funded contracts in some places.

I don't pretend (JRN) to have the answer to this dilemma. Both angles are clearly important.

Keyboard Navigation

The application should be navigable with minimal key-presses using the keyboard alone. Most standard HTML elements already behave properly with a keyboard, but as soon as we modify their behavior they frequently do not. When modifying an existing HTML element or creating an entirely new control the behaviour should follow the same patterns as standard HTML elements. That is

  • the tab key should navigate focus between elements,
  • the space key should toggle the state of the element, if it has a state
  • the arrow keys should navigate focus withe the element
  • the enter key should action the element.

At the moment we don't intend to make use controls that should take focus over the standard set of HTML elements. If you as a widget developer decide that you need to do this, you should enable the keyboard navigation so that your widget becomes part of firstly the focus ring (eg the tab order), and then behaves correctly one it has focus. There is one caveat to remember here, that whatever you do, don't make your modifications to the behavior of the browser consume all the CPU available to the browser otherwise the experience will become unusable for all users, not just the ones in need of assistive technologies. There are some excellent libraries out there that make keyboard navigation easier to achieve and don't impact the usability of the application. The Fluid Project is creating such a component.

Shortcut Keys

In most web applications where the page content is well defined and constructed from a single source, key board navigation that uses the Ctrl, Alt, F and other control keys adds to keyboard accessibility, however in a widget environment this has to be co-ordinated if it is not to become extremely confusing. For that reason we are advising the control or shortcut keys are not used in a keyboard environment. Inside the container pages we may use shortcut keys to jump to certain parts of the portal page.

Correct and Complete Attributes.

Beyond simple keyboard navigation there are other assistive technologies that will do things such as read the screen. For these software components to work we must give them as much help as possible. This is done by ensuring that the markup we present to the browser contains the correct attributes to ensure that the screen reader says the right thing. Within the HTML standard there are attributes, such as alt and title that the screen reader will pick up. The HTML that use used to generate your a widget, and for that matter the surrounding portal. As a first step all static HTML delivered from the server must contain the correct standard HTML attributes to make a screen reader 'read' the correct meaning.


All styling that is applied to the HTML must be in css styles, and not as html elements within the page. This is to allow the user that wants assistance to manage the styling without be prevented from doing so by embedded styles. In addition styles should be scalable and the page should flow as the styles scale. For example, it should be possible to increase and decrease the font size of all text on a page, so that all the fonts change in size, and the page layout does not become unusable. In general the use of static sizes such as pixels should be be avoided.


The markup should flow, and the tags in the markup should be used for the meaning they were intended. ie the markup should be semantic. If a block of text is a paragraph it should be inside a <p> tag. If it represents a heading on of the <hx> tags should be used (eg <h1> ). If it represents a list, then perhaps <ul> should be used. Excessive use of <div> and <span> where the div and the span enclose content with real structure and meaning should be avoided, as most assistive technologies will not know that the content is anything other than a region of something unknown.


Where ever possible markup should be enhanced with Aria attributes to indicate the full meaning of the tags. This will enable a screen reader to make sense of a list and perhaps even a div. There is guidance from the W3C above, and examples of many common components. Where the markup is static, these tags should be placed into the markup.

Dynamic HTML and interactivity.

If you application or Gadget is going to present a user interface that changes then there are some addition guidelines to follow. In general it is a bad idea, both from performance and accessibility, to inject lots of individual HTML elements into the DOM within a browser. If you do this, several things will happen. The Browser will start to render you changes, perhaps before you want them to be rendered. IE6 is particularly bad at this. The performance of the application will go through the floor. DOM Element injection is spectacularly slow compared to other methods of manipulation. Worst of all, form a assistive point of view, is that the assistive technology will probably get confused. It will see multiple changes to the DOM, perhaps happening in mid stream communicating with the user, and may let the user know about the changes before they are complete.

There are however techniques for interacting with the DOM that do not cause as many problems, although we would like to discourage whizzy DHTML effects that don't add anything to usability or accessibility.

Where there is a component that needs to interact with the user and inform the user of changes to its state, ARIA has some attributes that can be modified in existing elements that will convey this information to the assistive technology. For instance if there is a DHTML slider component, that sets a value. A user relying on assistance will not know the value or be able to control the slider. Assuming the developer of the slider has already added keyboard navigation, so the arrow keys adjust the value of the slider, then the slider should also modify ARIA attributes on the slider component when the value of the slider changes. An example of this can be seen in the widget examples

So modification of attributes within existing elements is acceptable to achieve DHTML effects and feedback those changes to assistive technologies.

Acceptable DHTML

It would be too restrictive to say that all DHTML is bad. In fact much of the MySakai approach depends on the use of AJAX and DHTML. However we must treat the updates as bulk updates. So for instance, when we bring up a search box to display search results it should be populated with search results containing all the correct ARIA markup in a single operation, by setting the innerHTML value of the containing element. In this way the new content of the result set is read, with the correct Symantic and ARAI markup in a single block.
This also has huge performance benefits, and in tests we have see more than 2 orders of magnitude difference in speed between a single innerHTML DOM injection and element by element DOM manipulation.

Legal Requirements and Important Guidance

UK Guidance

The BSI (British standards Institution) published the "Guide to good practice in commissioning accessible websites" PAS 78. This document has been developed in collaboration with the Disability Rights Commission. Other DRC publications on accessibility are available here. Note section 8 : Accessibility testing and maintenance, says that "All organizations, regardless of size, should ensure that those testing the website are different from those developing it." (ref PAS 78 : 2006 8.1.2)

Canada Guidance

This is perhaps in the wrong place because it is not so much guidance on applying the law as work towards making things better. But the Canadian government has pulled a lot of thinking together in this document . Among many other things it contains some very useful personas to help us think about who we are trying to help.

Accessibility and UK Law (this is not prepared by experts so do not assume this represents sound legal advice)

It is against UK Law to discriminate. The Disability Discrimination Act (DDA) from the Disability Rights Commissions (DRC) sets out a specific Code of Practice for service providers i.e. anyone providing a service to the public, including those concerning web sites.

The Code of Practice, specifically mentioning Web sites is included in Part III of the DDA Rights of Access for the provision of goods, facilities and services and states :

  • Section 7.22 states "For people with hearing disabilities, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include one or more of the following : (see bullet number 10) accessible Web sites."
  • Section 7.27 states "For people with visual impairments, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include one or more of the following : (see bullet number 7) accessible Web sites."

Download the full DDA Code of Practice PDF File (660Kb)

Accessibility and US Law (this is not prepared by experts so do not assume this represents sound legal advice)

The United States are covered by Section 508 (section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology), the full set of standards can be seen at:

Accessibility increases Usability

Not everyone uses the same technologies and equipment to access the Web. Web pages therefore need to be able to be viewed on different computers such PC's Mac's and Linux systems, and a variety of browser applications, also considering that not all visitors will have powerful computers or fast internet connections. These issues all form part of Web accessibility.

Ensuring that Web sites on the internet can be viewed by as many people as possible is paramount and the World Wide Web Consortium Web Content Accessibility Guidelines 1.0 set out the principles for compliance.


We are learning what to do in this area, and the version control on this page should show how and what we have learned. If you have read this page and can see things that are wrong, please help, either by editing the page or by adding comments.

Thank you.

1 Comment

  1. Hi Ian,

    This is a nice summary of DHTML accessibility fundamentals. Nice work! I've included some fairly in-depth comments below in the hope that I can help clarify a few issues.

    Keyboard Navigation

    In your keyboard navigation section, you mention that you "don't intend to make use of controls that should take focus over the standard set of HTML elements." Does this mean that you're not planning to include support for keyboard navigation using the arrow keys in your widgets? If so, I'd encourage you to reconsider where appropriate.

    Rich client-side user interfaces have the potential to significantly improve user experience, particularly in regards to keyboard navigation. In traditional Web applications, the Tab key can be a pretty tedious way to navigate around the page. One of the most interesting problems we encountered in Sakai, uPortal, and other applications while doing UX Walkthroughs was how time-consuming it is to navigate deeply within a page. The Tab and Shift-Tab keys provide only a one-dimensional way to move forward and backward through every link and form element on the page. On fairly dense pages, such as portals and dashboards, you often have to press the Tab key dozens of times to get to the section you need.

    With JavaScript-driven pages, the interface can more readily be grouped into discrete chunks of functionality. Significant sections of the page – gadgets, in your case – can be accessed using the arrow keys instead of the Tab key. Since the arrows provide two-dimensional control, this technique provides a speedy and effective way to get to your desired section of the page. The user can then tab into the section and navigate conventionally from there. This is the kind of navigation scheme we've built into the Layout Customizer, and early test results suggest it's a significant improvement.

    For several other designs you're planning in MyCamTools, you may want to consider supporting navigation with the arrow keys. File list views, progress bars, sliders, trees, and other controls should all be navigable in this way, particularly if they have ARIA roles attached (and they should). We've been participating in a W3C effort to create a keyboard accessibility style guide intended for widget developers. While I don't agree with all of these recommendations, it's a really good starting point for learning how to support familiar keyboard interactions.

    One other detail regarding keyboard accessibility: your list of patterns for conventional HTML keyboard navigation is slightly out of sync with the conventions for a DHTML environment. The correct behaviour for the Tab, Arrows, Enter, and Spacebar keys is described in my DHTML Developer's Checklist.


    For any custom controls such as the ones I mentioned above, the only way to make these accessible is by providing ARIA roles and states. ARIA, which stands for Accessible Rich Internet Applications, is a draft specification from the W3C that defines special attributes to convey additional information about user interface controls. Designed to fill the gap between standard HTML tags and more varied types of controls found in rich Internet applications, ARIA provides roles and states that describe the behaviour of most familiar UI widgets.

    ARIA roles and states are designed to be interpreted automatically by the browser and translated to the operating system's native accessibility APIs. Assistive technologies are thus able to recognize and interact with custom DHTML controls in exactly the same way that they do with their desktop counterparts. Assuming widget developers take the time to make their widgets follow convention, we can provide a more consistent user experience than was possible in the previous generation of Web applications.

    At the moment, Firefox is the only browser that supports ARIA, but Microsoft and Opera are implementing ARIA in their next versions. There has been a bit of flux in the syntax of ARIA attributes, so I'd strongly recommend using a library such as jARIA to hide away the inconsistencies. I expect future versions of jQuery to ship with ARIA support built right in.


    One way to avoid some of the complexity of adding keyboard handlers and ARIA semantics is to use a DHTML toolkit. Two choices immediately come to mind. Dijit, the widget library for the Dojo toolkit, contains the largest number of fully accessible controls. We've had several Fluid-affiliated developers involved with this work for over a year now, and they've made significant progress in adding keyboard navigation, ARIA roles and states, and high-contrast styling to many of their widgets.

    Since we like jQuery so much, we're also working closely with the jQuery UI community to help implement accessibility in their widgets as well. It's a safe bet that if you start using jQuery widgets now, you'll have a viable upgrade path for accessibility support in the future.

    I know that you've been using Ext for some of your recent code. We've heard a bit of interest from the Ext development team regarding ARIA and accessibility, but nothing definite at this point. We can keep our fingers crossed.

    Dynamic Page Updates and Live Regions

    Your section on "Dynamic HTML and interactivity" reflects some possible confusion. You mention performance issues here that are arguably quite separate from the accessibility concerns of dynamic updates.

    The first thing you should know is that dynamic page updates, at the current time, are often met with complete silence from screen readers. Most assistive technologies assume that the Web consists of static, document-based pages. They simply don't expect chunks of content to be updated on the fly without triggering a full browser refresh. It is only recently, with the emergence of ARIA, that screen readers are becoming aware of dynamic updates.

    Even assuming the assistive technology knows about the potential for live page updates, there are still some interesting questions to be answered, many of which are context-dependent. Which controls on the page can trigger a dynamic update? What types of DOM manipulations are relevant to the user? Is it appropriate to interrupt a user mid-stream to provide them with information about the update? The ARIA Live Regions attributes are designed to provide developers with the markup required to communicate their intentions to the assistive technology. ARIA includes features such as politeness levels, which specify when it is okay to interrupt a user with information about a live update, and for which types of data. The Mozilla Developer Center has a great overview of live regions if you're interested in learning more.

    Unfortunately support for live regions is still in its infancy. There are, however, some workarounds to consider while we wait for comprehensive live regions support. One of the techniques you can use is to strategically move keyboard focus to the information that has changed. So for example, if you ask the user to fill out a form that will be automatically submitted and validated by AJAX, you can programmatically throw focus onto the the validation status message. This will require dynamic modifications to an element's tabindex, and isn't appropriate for all situations, but it can be helpful in easing the confusion of live updates. Another technique is build your user interfaces using simple, semantic HTML delivered from the server and enhance it incrementally with rich interactivity. That way, you can still support the more traditional page-refresh model in suboptimal conditions, such as with browsers or ATs that don't fully support DHTML.

    Back to your point about DOM manipulation. Contrary to your assertion, I'd argue that under many circumstances, batch updates to a page can improve the usability and accessibility of a site because it will provide less interruptions for the user. In other cases, smaller, more frequent page updates may be more effective for time-sensitive information. This is a classic "it depends" question. The aria-atomic property lets you specify if updates should be read as a whole or in more frequent chunks.

    I hope this information is helpful in your effort to learn about DHTML accessibility. Don't hesitate to get in touch if you have any questions or need advice on how to implement these techniques in your work.