| - Examining the HTML Under the Covers|
Websites and web applications have the opportunity to provide additional information to persons with disabilities to help them understand and navigate more easily. Some of this information is visible to all users and can enhance their experience. Some of it is transparent to sighted users and provides context for persons with visual, auditory or motor limitations.
Code reviews can also be accomplished through direct examination of HTML. A useful guide for determining whether a site addresses accessibility through properly crafted HTML is IBM's Web Accessibility Checklist:
Under-the-covers QuestionsIs content separated from presentation through CSS?
Do pages have frames?
- Are buttons and other controls text-based?
- Are tables used for data and not layout?
- Does page content linearize?
Are headings hierarchical?
- Are they necessary? If so, do they have meaningful titles?
Are tables properly structured?
- Is punctuation provided in headings to control screen readers?
Are forms properly structured?Are forms organized by subject area?Are labels associated with input boxes?Are XHTML navigation landmarks taken from XHTML2? See: The XHMTL Role Attribute (Don't use 'skip to main content' - these roles are much more comprehensive.)Has a navigation section been identified on each page (role="navigation")?Do all navigation landmarks have a title including customer ARIA regions?Do Rich Internet Application widgets properly support ARIA and follow specified navigation rules?Do Rich Internet Application widgets follow the tab to container and arrow convention?Are keyboard mnemonic conventions consistent for context menus and a limited set of UI widgets?Are application and document areas in web pages properly defined to assist assistive technology with keyboard navigation? (A screen reader should not be in browse mode in a web application.)Does UI componentry provide rich hint, help, or tooltip text by establishing a relationship between the UI widget (could be a form control) and help information? For example, ARIA provides a describedBy and Tooltip relationship for these situations.Do all forms support extended ARIA form information, such as required and invalid?Are ARIA states and Properties synchronized with CSS style properties?Do UI components supporting multiple selections or options repeat option text?
- Do they contain headers and summaries?
- Are table cells associated with headers?
- Are they used for data and not presentation?
- If tables are necessary for presentation, are they identified as such? E.g.: role=:"wairole:presentation"