Accessible web design		Content & navigation • HTML • Interactive & other media • WebCT accessibility issues • Validation

Advanced HTML

More complex html functions with accessibility implications, include forms, frames, HTML 4.0, dynamic HTML and dynamic web pages (web applications). Use of these elements should be carefully considered and, in some cases, eliminated or minimised.

Forms

Forms should be simple and straightforward in their layout, and controls should be adjacent to their relevant labels. HTML markup can be used to associate the controls explicitly with their labels.
See http://www.webaim.org/tutorials/context#12.4 for information on using the 'label' element.

Text boxes in forms should have default content that suggests the kind of information the user should enter.

Users with screen readers or unable to use a mouse can use the TAB key to access form elements - use the 'tabindex' attribute to define the order of elements. The following list shows elements that support the tabindex attribute:

• <A>
• <AREA>
• <BUTTON>
• <INPUT>
• <OBJECT>
• <SELECT>
• <TEXTAREA>

See http://www.webaim.org/tutorials/device#9.4 for more information on using 'tabindex'.

Here are example form controls with accessibility features added: http://www.webaim.org/howto/forms4

The HTML 4.0 'accesskey' attribute supports specification of direct keyboard access to form controls.
See http://www.webaim.org/tutorials/device#9.5 for more information on using 'accesskey'.

For information on creating accessible forms, see http://www.webaim.org/howto/forms.

Frames

Minimise use of frames to avoid confusion
If it is necessary to use frames, ensure that frames are individually titled within the main frameset with their function (eg title frame, navigation frame, content frame), and that all links are also available from the main content frame. See http://www.webaim.org/tutorials/context#12.1 for how to do this.

One major disadvantage of frames is the difficulties that arise with bookmarking and referring URLs (the URL is the web address of the page, which in the case of a frames-based site is generally the main frameset, or entry page). Setting up individual framesets for each page is one way to avoid this, although this goes some way towards negating the convenience of using frames.

When using a development application such as WebCT, the use of frames is intrinsic to the application, and is not optional. (See WebCT accessibility issues).

Dynamic HTML

Unfortunately, most DHTML (client-side scripted HTML, which is usually accomplished with Javascript) is totally inaccessible to the keyboard. This means that individuals who are dependent upon the keyboard, whether it be because of muscular limitations or visual disabilities, are unable to use the DHTML functions on your pages.

A commonly used function is the onMouseover command. If an onMouseover (or similar) element does not contain any important information (e.g. the script causes a button to “glow”), then there is no consequence for accessibility. If this scripted event reveals important information, such as a drop-down menu, then a keyboard-accessible alternative is required.

Using 'logical' (eg onSelect) rather than 'device-dependent' (eg onMouseOver) event handlers in scripts is recommended. See http://www.webaim.org/tutorials/device#9.3 for more information.

Dynamically generated webpages

Pages that are generated dynamically from databases require user-input via form fields. See Forms (above) for information about accessible form design. The pages generated should have the same accessibility checks as regular HTML.

Dynamic pages also present problems in archiving for offline-browsing.

Go back to HTML

Or continue to Interactive and other media.