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)
- W3C ARIA Pages http://www.w3.org/WAI/intro/aria
- W3C ARIA Specification http://www.w3.org/TR/2008/WD-wai-aria-20080204/
- W3C ARIA Primer http://www.w3.org/TR/wai-aria-primer/
- W3C ARIA Best Practices http://www.w3.org/TR/wai-aria-practices/
- Illinois Widget Examples http://test.cita.uiuc.edu/aria/
- Illinois Testing Tool for Firefox http://firefox.cita.uiuc.edu/
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.
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.
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 http://test.cita.uiuc.edu/aria/slider/slider1.php
So modification of attributes within existing elements is acceptable to achieve DHTML effects and feedback those changes to assistive technologies.
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
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)
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: http://www.section508.gov/.
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.