The Fluid approach to UX Walkthroughs involves performing a Heuristic Evaluation and Cognitive Walkthrough, often at the same time. By using a combined approach, an evaluator can gain insight beyond that found by performing a single method in isolation. A UX Walkthrough can also involve an under-the-covers accessibility Code Accessibility Markup Review of the HTML.
Our aim for Fluid is Software that works - for everyone. This means that we assess accessibility as well as usability. Rather Additionally, rather than having two separate inspections for usability and accessibility, we use a unified approach that addresses both areas.
When evaluating an application or website using the a Fluid approachUX Walkthrough, you will be able to determine both:
Code Review - 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"
| Accessibility Markup Review|
| Accessibility Markup Review|