Website accessibility is the work of making information and tasks usable by people with different abilities, devices and interaction methods. It is not a final audit that can be solved by adding a plugin; it is a set of decisions about structure, content, controls, visual design and testing.
A practical first pass should focus on common barriers: missing labels, weak contrast, keyboard traps, unclear focus, content available only on hover, and motion that makes the page difficult to use. Automated checks can find some problems, but they cannot judge every real user journey.
Key takeaways
- Use semantic elements and logical headings.
- Complete every task without a mouse.
- Measure text contrast in real interface states.
Text contrast minimums to check
| Text type | Minimum contrast ratio | Practical note |
|---|---|---|
| Normal text | 4.5:1 | Check the actual rendered text and background colors, including hover, disabled and error states. |
| Large text | 3:1 | Large text generally means at least 18 pt regular or 14 pt bold; follow WCAG definitions when evaluating. |
Contrast is only one part of accessibility. Keyboard operation, focus visibility, semantics, labels and task flow still need manual checks.
Use semantic structure
Use headings to represent the document outline, buttons for actions and links for navigation. Give each page a meaningful title and use landmarks such as header, navigation, main and footer appropriately. A clickable div may work with a mouse but usually needs extra keyboard behavior and accessible naming. Native HTML controls provide established behavior that custom widgets must otherwise reproduce. Keep heading levels logical and ensure that a heading describes the section that follows it.
Make keyboard navigation predictable
Every interactive element should be reachable using the keyboard and should show a visible focus indicator. Tab order should follow the reading and task order, not jump unpredictably around the page. Menus and dialogs need clear open, close and escape behavior; focus should not become trapped in a closed component or disappear behind a sticky header. Test the site without a mouse, including forms, menus, carousels and any custom controls that were added for visual effect.
Check text and interface contrast
Contrast should be measured for the actual text and background combination, including hover, focus, disabled and selected states. WCAG 2.2 AA generally calls for a 4.5:1 contrast ratio for normal text and 3:1 for large text, with separate rules for non-text interface elements. Do not rely on a color change alone to communicate an error or active state. Use readable font sizes, comfortable line height and sensible line lengths, particularly for long-form content.
Build forms that explain errors
Every field needs a visible or programmatic label, and instructions should appear before a person needs them. Associate error messages with the relevant fields, explain how to fix the issue and preserve valid values when submission fails. Required fields should be identified clearly. Placeholder text is not a substitute for a label because it disappears during entry and may have low contrast. Test autocomplete, validation messages and status announcements with keyboard navigation and a screen reader when possible.
Respect zoom, reflow and touch
At narrow viewport widths and high zoom, content should reflow without forcing horizontal scrolling for ordinary paragraphs. Tables and code samples may need their own controlled scrolling, but the overall page should remain usable. Buttons and links should have practical touch targets and enough space to avoid accidental activation. Avoid fixed-height text containers that clip content when a visitor increases text size. Test the actual page rather than assuming that a responsive framework automatically guarantees accessibility.
Make motion optional
Animations should communicate state or add restrained emphasis without hiding important information. Respect the prefers-reduced-motion setting and remove or simplify nonessential movement when it is enabled. Avoid rapid flashing, scroll hijacking and long sequences that delay access to the content. Pointer-following effects should have touch and keyboard alternatives. Ensure that the page remains understandable if JavaScript or WebGL is unavailable, and clean up animation listeners when components unmount.
Combine automated and manual testing
Automated tools can identify missing labels, some contrast failures and common markup issues, but they cannot reliably determine whether instructions are understandable or whether a keyboard interaction is confusing. Pair automated scans with keyboard testing, browser zoom, mobile checks and task-based review. If possible, include people who use assistive technologies in usability testing. Record issues by impact and fix the barriers that prevent important tasks before polishing minor visual details.
Test the complete task with a keyboard
Choose important journeys such as navigating to a service, filling a contact form, opening a menu or reading an article. Use Tab, Shift+Tab, Enter, Space and Escape where appropriate, and check that focus remains visible and moves in a logical order. A modal or mobile menu should not trap focus unexpectedly, and a closed overlay should not leave hidden controls keyboard-accessible. Do not require hover to reveal important links or explanations. Native links, buttons, labels and form elements usually provide reliable behavior with less custom code than clickable generic containers. Test with the actual content because long headings and validation messages can expose focus and layout problems.
Check contrast, zoom and responsive reading
Normal text should have sufficient contrast against its actual background, including muted text, badges, placeholders and hover states. Do not judge contrast from a color palette sample alone because transparency and overlays change the result. Zoom to 200 percent and check that content reflows without losing information or forcing two-dimensional scrolling for ordinary text. Tables and code blocks may need their own bounded scrolling region, but the entire page should not overflow horizontally. Ensure buttons and links are distinguishable without color alone. Layouts should remain understandable when the page is narrow, the font size is enlarged or a visitor uses a high-contrast setting.
Respect motion and communicate errors
Animations should support hierarchy rather than carry essential meaning. Provide a reduced-motion experience for scroll reveals, parallax and animated backgrounds, and avoid rapidly flashing content. Form errors should identify the affected field, explain what needs to change and remain available to assistive technology. Status messages such as successful submission should be announced appropriately instead of only changing a color or icon. Images need alternatives based on purpose: informative images should convey relevant information, while decorative illustrations can use empty alt text. Accessibility work is iterative, so combine automated scanning with keyboard checks, manual inspection and feedback from people using different devices and assistive technologies.
Document reusable interaction patterns
When a site uses the same menu, dialog, accordion, card or form component across multiple routes, define its expected accessible behavior once and test it consistently. A navigation menu should expose its expanded state, support keyboard activation and close predictably. An accordion summary should work as a native control and communicate whether its panel is open. A form should associate labels and errors with the relevant inputs, preserve the entered values after a recoverable error and announce a submission result. A carousel should allow pause or direct navigation if movement affects reading, and it should not move focus unexpectedly. Write a small checklist for these shared components and include it in review whenever the component changes. The goal is not to add accessibility attributes indiscriminately; it is to use semantic HTML first and add ARIA only when native behavior is insufficient. Check focus visibility against the actual background and ensure overlays do not obscure the focused item. Respect reduced motion and do not make a hover effect the only way to find content. Documenting the pattern saves future work because each page inherits behavior from the shared component. It also helps prevent a visual redesign from accidentally removing keyboard support that was previously working.
Practical checklist
- Use semantic elements and logical headings.
- Complete every task without a mouse.
- Measure text contrast in real interface states.
- Associate form labels, instructions and errors correctly.
- Test zoom, mobile reflow and reduced-motion behavior.
Frequently asked questions
Does passing an automated accessibility scan mean a site is accessible?
No. Automated scans catch a subset of issues. Keyboard, zoom, screen-reader and task-based testing are still necessary. Combine automated checks with keyboard and manual review; automated tools cannot fully judge wording, focus order or context.
What contrast ratio should normal text target?
WCAG 2.2 AA generally specifies at least 4.5:1 for normal text and 3:1 for large text, subject to defined exceptions. Fix issues in shared components first because one correction can improve every page that uses the same pattern.
Do animations need to be removed for accessibility?
Not all animation is a problem. Provide reduced-motion behavior, avoid harmful effects and ensure the content and controls remain usable without motion. Combine automated checks with keyboard and manual review; automated tools cannot fully judge wording, focus order or context.
Can an automated scan prove a website is accessible?
No. Automated tools can find common problems, but they cannot reliably judge every label, reading order, instruction or task flow. Combine scans with keyboard navigation, zoom, focus checks and manual review of important user journeys.
Sources & references
Documentation and references used to check the technical and practical guidance in this article.
Accessibility improves the reliability of the experience for more people and more situations. Use semantic HTML, test keyboard paths, measure contrast, explain errors and make motion optional. Treat the checklist as a repeated development practice rather than a one-time badge.
Have a related project or need a second opinion? Share the context and start a conversation .
