Web Access Centre

Dynamic menus - Web Access Centre

Summary: Learn more about accessible JavaScript menus and dynamic content.

• Techniques
• Testing tips
• Further information
• Website Accessibility Initiative compliance
• Other pages about scripts and forms

---

Dynamic menus, also known as drop-down menus, can cause a number of accessibility issues. They are difficult to make keyboard accessible for people who do not use a mouse and can be awkward to use for people with screen magnification.

If they consist of text, users who require to use their own text and background colour settings can get transparent menus overlaying the page content - often difficult or impossible to read. If they consist of graphics rather than actual text they can't be increased or decreased in size in the way that text can. Some users may therefore find them difficult or impossible to read.

Techniques

• Ensure keyboard accessibility of links within the menu, especially the top-level links. Try not to rely solely on mouse only controlled events, such as onClick or onMouseOver as these are not available to screen reader users. Each top-level link should be a link in its own right to a section home page which then provides the same menu options (as provided in the drop down menu) as static text links. This top link should be available with JavaScript switched off and should be text rather than an image of text.

Using images of text is problematic for low vision users as they can not be enlarged via the enlarge text option in a browser. Screen magnification users lose information, as images of text will become pixellated when scaled.

• Use flexible positioning to construct menus. This allows users to resize the font sizes in the menu within their browser to suit their needs. Care must also be taken to ensure that the "boxes" which contain the menus can expand to accommodate larger text if users have their browsers set to use larger font sizes.
• Provide an HTML alternative to the JavaScript functionality. This could be a <NOSCRIPT> inserted where the script itself would be active in the web page. This means that if scripting is not available the <NOSCRIPT> content will be presented in its place. Care must be taken to ensure that at least the top-level link is accessible.
• CSS being unsupported or disabled within the browser should not prevent users from being able to access the links in the menus. This means that links should still be readable against the background is colours are lost within the boxes in the menu.
• Provide an on / off switch so users can switch off drop down menus if they cause a problem or if they simply prefer to navigate without them. This switch could appear in the home page or an accessibility help page or section.

This benefits screen magnification users as often the dropdown menu covers up everything on the screen that they can see which can be especially frustrating when you want to look at the content behind the menu.

Testing tips

Verify that menus are accessible when JavaScript is switched of ie the top-level link does not rely on JavaScript to function. Check also that the top-level link is not and image and if it is there is an alternative text link elsewhere on the page.

• Accessibility toolbar - Go to IE Options - Toggle JavaScript (switches support for JavaScript off and on) and Doc Info - Identify Applets / Scripts [new window].
• Browser - Go to view - Source. Edit - Find - "script" and Tools - Internet Options - Security - Custom level Scripting then check "Disable active scripting".
• Text browser - If links do not open JS is present as Lynx has no support for JS.

Further information

• Accessible JavaScript menu - created by Brothercake.

Website Accessibility Initiative compliance

• 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. Priority 2
• 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. Priority 1
• 6.4 For scripts and applets, ensure that event handlers are input device-independent. Priority 2
• 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. Priority 2
• 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. Priority 1
• 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies – If functionality is important. Priority 2
• 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. Priority 2
• 9.4 Create a logical tab order through links, form controls, and objects. Priority 3

For more information on techniques visit the Web Accessibility Initiative techniques page.

Other pages about scripts and forms

• JavaScript
• Dynamic menus
• Forms
• JavaScript in forms
• Time outs, page refreshes and redirects

Back to Design & Build

For Web Access Centre updates email webaccess@rnib.org.uk

Content author: webaccess@rnib.org.uk

Last updated: 08/04/2008 18:38