Accessibility and Inclusive Content
Screen Reader Content Order Map
Compare visual layout with meaningful DOM reading order and keyboard focus order for assistive technology users across responsive and dynamic states.
Free editable Markdown · Accessibility testers, designers, and front-end teams ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Test context
- Page/component and build
- [URL/version]
- Primary task
- [User goal]
- Viewport and zoom
- [Dimensions/percentage]
- Browser and screen reader
- [Names and versions]
- Starting state
- [Collapsed, signed in, errors, other]
- Relevant landmarks
- [Header, main, navigation, aside, footer]
- Tester and date
- [Name; YYYY-MM-DD]
- Applicable standard/process
- [Reference]
Order record
- Element ID
- [Stable label]
- Visible element
- [Text/control]
- Visual position
- [Sequence]
- DOM/read sequence
- [Sequence and announcement]
- Focus sequence
- [Sequence]
- Associated instruction/status
- [Relationship]
- Expected order
- [Reason]
- Issue
- [Confusing, premature, missing, trapped, return failure]
- Responsible component
- [Source]
Verification checks
- Main content and landmarks provide efficient navigation.
- Reading sequence preserves visual and semantic relationships.
- Focus order follows task dependencies.
- Instructions occur before governed inputs or actions.
- Status and error messages are announced in useful context.
- Modals manage entry, containment, close, and return.
- Responsive layouts retain coherent order.
- Shared fixes are retested across affected states and pages.
How to use this template
- Define the task, viewport, state, screen reader, browser, and interface version.
- Number meaningful elements in visual, DOM reading, and keyboard focus order.
- Compare sequence with content relationships, instructions, dependencies, and expected task flow.
- Test responsive and dynamic states, including focus entry, announcements, and return.
- Document defects, responsible component, remediation, verification, and regression scope.
Map three orders separately
Record visual order, DOM reading order, and keyboard focus order for each meaningful item. They can differ for valid reasons, but the sequence must preserve understandable relationships and predictable interaction. Number landmarks, headings, instructions, fields, controls, status messages, and supporting text. Check responsive layouts because columns may visually reorder while DOM order stays fixed. Content that looks adjacent may be announced far apart if components are assembled from separate regions.
Follow task dependencies
Instructions should be encountered before the field or control they govern, status should be announced near the action that caused it, and dialog content should receive appropriate focus without exposing inaccessible background interaction. A screen-reader user should not reach “Submit” before important conditions or encounter an error without field context. Avoid positive `tabindex` values and visual CSS reordering used as a substitute for a coherent DOM. Confirm skip links and landmarks provide efficient routes.
Include dynamic and return states
Open menus, accordions, modals, validation messages, notifications, filters, and asynchronously inserted results. Record focus entry, announcement, action sequence, close behavior, and focus return. Test after zoom and at mobile breakpoints. Automated tools may detect some order and focus issues but cannot determine whether the narrative makes sense. Pair technical observations with task-based review and log shared-component fixes that affect multiple pages.
See the fields in context
Fictional example: course filter drawer
Learn Harbor is an invented interface and the accessibility behavior is illustrative.
- Finding: The fictional mobile drawer appears visually before results, but its DOM is after the footer.
- Impact: Screen-reader navigation reaches unrelated content before filters, and focus returns to the page top after close.
- Remediation: Place drawer markup near its trigger, move focus to its heading, keep interaction within it, and return focus to “Filter courses.”
- Status: Announce the result count after applying filters without moving focus unexpectedly.
- Verification: Test reading and focus sequences at mobile and desktop states with the named environment.
Frequently asked questions
Are reading order and focus order the same?
No. Reading order covers content sequence, while focus order covers interactive elements. Both should support the same understandable task.
Can CSS reorder content visually?
It can, but large differences from DOM order may confuse keyboard and screen-reader users. Prefer a coherent source order.
Do automated tools validate meaningful order?
They can reveal some technical issues, but human task-based testing is needed to judge whether relationships and sequence make sense.
What should happen after a modal closes?
Focus generally returns to the control or a logical place related to the triggering action, following the component's expected accessible behavior.