Many teams reduce accessibility to “add alt text to images.” Other barriers have greater impact: menus that require mouse hover, dialogs that cannot be closed, form errors that screen readers miss, and focus that moves behind an overlay.
A more reliable principle is to use native HTML behavior first, adding ARIA and custom keyboard logic only when a custom component is genuinely necessary.
01 Semantic HTML Is the First Layer
Use button for buttons, a for links, headings for content hierarchy, and label elements for form controls. Native elements include substantial keyboard and assistive-technology behavior.
Using a div as a button makes clicks, keyboard operation, focus, and accessible naming the developer’s responsibility.
02 Make Every Function Operable by Keyboard
Users should be able to Tab to controls, see focus, activate with Enter or Space, and close appropriate overlays with Escape.
Focus order should follow the visual and DOM logic. Avoid positive tabindex values that create an unmaintainable order.
Web Accessibility Development Checklist
| Area | Baseline Requirement | Common Error |
|---|---|---|
| Navigation | Skip repeated content; keyboard-operable menus | Hover is the only entry |
| Headings | Hierarchy represents content structure | Heading tags chosen by font size |
| Images | Purposeful alt text or empty alt | Keyword stuffing or filenames |
| Forms | Labels, associated errors, clear instructions | Color-only errors; placeholders replace labels |
| Dialogs | Focus enters, stays, and returns after close | Focus remains in the background or disappears |
| Dynamic content | Announce important state changes | No feedback when loading completes |
| Color | Sufficient contrast for text and controls | Small light-gray text; color-only meaning |
03 ARIA Cannot Repair Incorrect Structure
ARIA supplements roles, names, states, and relationships. It should not turn every div into a complex widget.
Custom comboboxes, tabs, trees, and similar components should follow established interaction patterns and be tested with assistive technology.
04 Make Form Errors Findable and Understandable
Associate errors with fields and explain the specific problem and correction. After submission, move focus or provide a summary that leads to errors.
Required state, formats, and help text cannot rely on red color or an icon alone.
05 Manage Focus and Announcements in Dynamic Interfaces
Single-page route changes, asynchronous saving, toasts, and loading results need to communicate what happened to screen-reader users.
Do not over-announce; frequent messages become disruptive.
06 Combine Automated Checks With Manual Testing
Automated tools find some semantic, contrast, and attribute errors, but cannot judge whether copy is accurate, focus is logical, or a workflow is usable.
At minimum, conduct keyboard walkthroughs, screen-reader samples, zoom tests, and high-contrast checks, and include disabled users in testing important systems.
Frequently Asked Questions
Does adding ARIA make a page accessible?
No. Start with correct HTML and interaction; ARIA is supplementary.
Does every image need alt text?
Informative images need appropriate alt text. Purely decorative images should use empty alt text to avoid noise.
Will a screen reader announce hidden content?
It depends on the hiding technique. Visually hidden content and content removed from the accessibility tree are not the same.
How many issues can automated tools cover?
Only a subset. Keyboard behavior, semantic understanding, and real tasks still require manual testing.
Does accessibility restrict visual design?
It adds necessary constraints, but clear hierarchy, readability, and consistent interaction usually improve the experience for everyone.
| Service | View |
|---|---|
| Related service | View service details |
| Project inquiry | Contact JVDS |
| Design and website articles | View all articles |
Link copied
