Accessibility for Simple to Moderate-Complexity DHTML Web Sites
Cynthia C. Shelly, George Young · 2007 · Proceedings of the 2007 International Cross-Disciplinary Conference on Web Accessibility (W4A) · doi:10.1145/1243441.1243460
Summary
This detailed technical paper from Microsoft provides practical design and coding techniques for making Dynamic HTML and AJAX applications accessible using the browser and assistive technology capabilities available in 2007 — deliberately without relying on the then-in-progress WAI-ARIA specification. The authors define a continuum of web complexity: static HTML (traditional documents), simple DHTML (documents with client-side validation and pop-ups), moderate-complexity DHTML (applications with toolbars, menus, sliders, and asynchronous updates), and complex DHTML (spreadsheet-like applications requiring ARIA). The paper focuses on the moderate-complexity tier, arguing that most common UI widgets can be mapped to HTML constructs with "close-enough semantics" through careful markup and scripting. The architectural foundation is the accessibility API chain: browsers map HTML semantics to platform accessibility APIs (like Microsoft Active Accessibility/MSAA), and assistive technologies read from those APIs. Since web developers cannot write directly to accessibility APIs, they must rely on how browsers map HTML elements — making correct semantic HTML the fundamental requirement. The paper's core principle is that links and buttons are the only HTML elements whose click events are device-independent (working with mouse, keyboard, and accessibility API triggers), so all interactive functionality must be built on these elements rather than divs or spans with onclick handlers.
Key findings
The paper provides detailed, working code examples for several common UI patterns. For larger click targets (e.g., an email message list), links within container elements pass clicks up to the parent link via click() method delegation. For hover pop-ups, a hidden link following the hoverable element provides keyboard and AT access to the same content triggered by mouseover. Menus, toolbars, and tree controls are all modeled as nested unordered lists of links, with CSS transforming the semantic structure into visual menu/toolbar/tree appearances and JavaScript toggling visibility via display properties. A slider is implemented using link-wrapped images for increase/decrease buttons with descriptive alt text, arrow key handlers via onkeypress, and drag support — all updating alt text on the slider nib to expose the current value to AT. For inline form validation errors, the technique modifies the label element's text to include the error message, so JAWS reads "Telephone number must be 9 digits edit" when the field is focused. For AJAX updates, since asynchronous DOM changes do not trigger navigate events that screen readers detect, the workaround uses a hidden iframe navigated to a timestamped URL, which does generate a navigate event and triggers the screen reader to update its snapshot of the page.
Relevance
This paper is a remarkable snapshot of pre-ARIA accessible web development — demonstrating both the ingenuity required to make dynamic interfaces accessible using only native HTML semantics and the limitations that motivated ARIA's development. Many of the principles remain directly applicable today: using semantic HTML elements for their built-in accessibility rather than styling generic elements to look interactive; ensuring all functionality is device-independent through proper element choice; maintaining DOM order that matches reading/tab order; and inserting dynamic content adjacent to the triggering element for natural discovery. The hidden-iframe hack for AJAX notification is a fascinating historical workaround that ARIA live regions eventually replaced properly. The paper's emphasis that "the only elements that should trigger actions are links and buttons" — because only their click events are device-independent — articulates a principle that accessibility practitioners still frequently need to enforce. For modern developers, the techniques for modeling menus, trees, and sliders as lists of links illustrate why ARIA roles were needed: these workarounds worked, but were fragile and required extensive knowledge of how specific screen readers interpreted HTML semantics.
Tags: web accessibility · DHTML · AJAX · JavaScript · keyboard accessibility · screen readers · semantic HTML · web development · assistive technology · dynamic content
Standards referenced: WCAG 1.0 · WCAG 2.0 · WAI-ARIA