Accessibility tests
We compared Ultimate Dropdown Menu against the WAI Web Content Accessibility Guidelines, and in our view it meets the criteria for Triple-A Conformance.
But compliance is a judgement call,
and we value practical feedback -
if you have any accessibility issues with the menu, or you find
a particular feature difficult or impossible to use, please do
let us know.
Below are the results of the accessibility audit we did.
Guideline 1 - Provide equivalent alternatives to auditory and visual content
Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 1.1 Provide a text equivalent for every non-text element. This includes: images, graphical representations of text, image map regions, animations, applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds, stand-alone audio files, audio tracks of video, and video. |
The menu can use up to three kinds of non-textual element:
|
| 1.2 Provide redundant text links for each active region of a server-side image map. | Not applicable. |
| 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. | Not applicable. |
| 1.4 For any time-based multimedia presentation, synchronize equivalent alternatives with the presentation. | Not applicable. |
| 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. | Not applicable. |
Guideline 2 - Don't rely on color alone
Ensure that text and graphics are understandable when viewed without color.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. | Color is used to convey rollovers, and whether links are visited or unvisited. These states can additionally be indicated with changes in border-style, and with normal, italic or oblique font-styling. You can also pass arbitrary CSS to link states, allowing you to use text-decoration, font-variant, or any other styling. |
| 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. | It's up to you to ensure that your implementation meets this checkpoint. A useful tool for testing is the Vischeck color deficit simulator. |
Guideline 3 - Use markup and style sheets and do so properly
Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 3.1 When an appropriate markup language exists, use markup rather than images to convey information. | The menu structure is based on HTML markup. |
| 3.2 Create documents that validate to published formal grammars. | The menu is valid to HTML 4 and XHTML 1.1 |
| 3.3 Use style sheets to control layout and presentation. | The menu styling is all CSS - no presentational attributes are used. |
| 3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. |
The navbar can have relative positioning. The navbar's x and y offset, its width, the dimensions of each menu, and the font-size of links, can all be specified in variable units - such as percentage or "em". |
| 3.5 Use header elements to convey document structure and use them according to specification. |
If you add a heading immediately before the navigation bar, this can help serial browsers to identify it from their "headings-list" or equivalent. You can also add headings inside the navigation tree - for example an <h3> around each top-level link - which should improve usability for serial browsers by allowing them to skip from branch to branch; again, using their "heading-reading mode" or equivalent. Internal headings also provide additional semantics that should help to distinguish a navbar link from a menu link. |
| 3.6 Mark up lists and list items properly. | The menu only works with a valid and well-formed UL structure. |
| 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. | Quotation markup is not used for formatting effects. |
Guideline 4 - Clarify natural language usage
Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 4.1 Clearly identify changes in the natural language of a document's text and any text equivalents. | Not applicable. |
| 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. | Not applicable. |
| 4.3 Identify the primary natural language of a document. | Not applicable. |
Guideline 5 - Create tables that transform gracefully
Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 5.1 For data tables, identify row and column headers. | Not applicable. |
| 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. | Not applicable. |
| 5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). | The menu does not use any tables. |
| 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. | Not applicable. |
| 5.5 Provide summaries for tables. | Not applicable. |
| 5.6 Provide abbreviations for header labels. | Not applicable. |
Guideline 6 - Ensure that pages featuring new technologies transform gracefully
Ensure that pages are accessible even when newer technologies are not supported or are turned off.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. | The navbar is still visible, and can still be used for navigation, when style sheets are not available. |
| 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. | The navbar does not change dynamically other than in browsers which support dynamic content. |
| 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. | The navbar can still be used for navigation when scripting is not available. |
| 6.4 For scripts and applets, ensure that event handlers are input device-independent. |
Well, as the HTML Techniques documentation concedes, no current user-agent implements device-independent event handlers. However, in so far as this checkpoint can be addressed, it has been: The main navbar is accessible to all browsers using the keyboard - normally Tab, Shift+Tab and Enter - but if a different device is used for equivalent commands, they'll work just the same as they normally would. For graphical browsers which support focus-event handling, and also for serial and legacy browsers, the whole navbar and menu structure is accessible using the keyboard. |
| 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. | The navbar is based on static HTML - it isn't dynamically generated. |
Guideline 7 - Ensure user control of time-sensitive content changes
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. | Not applicable. |
| 7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). | Not applicable. |
| 7.3 Until user agents allow users to freeze moving content, avoid movement in pages. | The only movement which occurs is the opening, closing or repositioning of menus. These are user-triggered events which don't happen on their own. |
| 7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. | Not applicable. |
| 7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. | Not applicable. |
Guideline 8 - Ensure direct accessibility of embedded user interfaces
Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies |
The main navbar is accessible to all browsers using the keyboard - normally Tab, Shift+Tab and Enter - but if a different device is used for equivalent commands, they'll work just the same as they normally would. For graphical browsers which support focus-event handling, and also for serial and legacy browsers, the whole navbar and menu structure is accessible using the keyboard. The existing keyboard functionality of screenreaders and other assistive devices will not, to the best of our knowledge, be affected by the menu script's keyboard handlers - an external device will take precedence and override the script. |
Guideline 9 - Design for device-independence.
Use features that enable activation of page elements via a variety of input devices.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. | Not applicable. |
| 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. | This is the same as 8.1 |
| 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. | This is the same as 6.4 |
| 9.4 Create a logical tab order through links, form controls, and objects. | The links can have tabindex attributes, if necessary, but the list itself is a logically-ordered structure. |
| 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. | The links can have accesskey attributes, although their use is discouraged because most browsers' implementation is broken in some way. |
Guideline 10 - Use interim solutions
Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. | All links open in the same window by default. Beyond that, it's up to you to ensure that your implementation meets this checkpoint. |
| 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. | Not applicable. |
| 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. | Not applicable. |
| 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. | Not applicable. |
| 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. | All the links are inside list-items - so in browsers which don't render the CSS that would visually separate links, the list-item bullets do this job instead. They also provide structural semantics which should help users of assistive devices such as screenreaders. |
Guideline 11 - Use W3C technologies and guidelines
Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. | The menu is valid to XHTML 1.1, works within XHTML served as XML, and uses the latest DOM scripting techniques in browsers that support them. |
| 11.2 Avoid deprecated features of W3C technologies. | No deprecated elements or attributes are used. All the styling is CSS, which allows users to override the menu styling with their own. |
| 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) |
The menu can be used within a content-negotiation or content-management system, to provide different versions to different users. Multiple style sheets can be created to offer user preferences, such as a stylesheet switcher. |
| 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. | Not applicable. |
Guideline 12 - Provide context and orientation information
Provide context and orientation information to help users understand complex pages or elements.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 12.1 Title each frame to facilitate frame identification and navigation. | Not applicable. |
| 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. | Not applicable. |
| 12.3 Divide large blocks of information into more manageable groups where natural and appropriate. |
The list-structure creates a navigational heirarchy, where links can be split into groups as appropriate. You can make it easier to find the navbar within a page by having a "skip to navigation" link, and by putting a "Site navigation" or equivalent heading immediately before it. You can also improve usability for serial browsers by adding headings inside the navigation tree, such as an <h3> around each navbar link. |
| 12.4 Associate labels explicitly with their controls. | Not applicable. |
Guideline 13 - Provide clear navigation mechanisms
Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 13.1 Clearly identify the target of each link | It's up to you to ensure that your implementation meets this checkpoint. |
| 13.2 Provide metadata to add semantic information to pages and sites. | The links can have semantic attributes, such as "rel" or "rev". The navigation list itself is a semantic structure, where the nesting of lists creates relational groups of links. |
| 13.3 Provide information about the general layout of a site (e.g., a site map or table of contents). | Not really applicable, but worth mentioning that since the menu structure is simple HTML you can easily share its data between multiple pages. For example, you could transform your menu structure into a sitemap, or conversely use the link structure from a sitemap to populate the menus on other pages. |
| 13.4 Use navigation mechanisms in a consistent manner. | The menu behaviors are internally consistent, in so far as they respond in an intuitive and predictable way. Beyond that, it's up to you to ensure that your implementation meets this checkpoint. |
| 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. | Indeed :) |
| 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. |
The navbar structure is a semantic group of links. If you add a heading immediately before the navbar this can help serial browsers to identify it, and you can improve usability for these browsers by adding headings inside the navigation tree as well. It's up to you to implement some kind of "skip navigation" link as necessary, which could be built directly into the navbar list itself, and then individually styled as appropriate. |
| 13.7 If search functions are provided, enable different types of searches for different skill levels and preferences. | Not applicable. |
| 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. | If you add a heading immediately before the navbar this can help serial browsers to identify it. For graphical browsers the nature of the navigation structure should be obvious from its appearance and behavior. |
| 13.9 Provide information about document collections (i.e., documents comprising multiple pages.). | Not applicable. |
| 13.10 Provide a means to skip over multi-line ASCII art. | Not applicable. |
Guideline 14 - Ensure that documents are clear and simple
Ensure that documents are clear and simple so they may be more easily understood.
| Checkpoint | How the checkpoint is addressed |
|---|---|
| 14.1 Use the clearest and simplest language appropriate for a site's content. | Not applicable. |
| 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. | The menu API can provide data to other kinds of process, such as speech output, or dynamic image generation. |
| 14.3 Create a style of presentation that is consistent across pages. | You can share the data from a single stylesheet so that your navigation looks the same on every page. |
