Accessibility guide 10
Website accessibility starts with ordinary customer tasks.
The short answer
Start by making every important task work without a mouse, keeping text readable and resizable, labeling controls, using meaningful headings, writing useful image alternatives, captioning spoken video, and explaining form errors clearly. Automated scans can find some defects, but keyboard, screen-reader, zoom, and human task testing are still necessary. This guide is practical information, not legal advice.
How this guide was made. Parcha Lab synthesized firsthand service scope and the official sources listed below. AI assisted with drafting and structural checks.Human review byMikeon.
Accessibility is access to the business.
The U.S. Department of Justice explains that inaccessible web content can deny people with disabilities equal access to goods and services. Its examples include poor contrast, missing text alternatives, videos without captions, forms without labels or useful errors, and mouse-only navigation.
Legal obligations depend on the organization and facts, so a checklist cannot determine compliance. Use qualified legal advice for legal questions. For design and engineering, the Web Content Accessibility Guidelines provide a testable technical reference; W3C advises using WCAG 2.2 for future applicability.
Related: Review Parcha Lab's public FAQ
Build a page that still makes sense without sight or a mouse.
Use one descriptive main heading, a logical heading order, landmarks, lists, tables only for tabular data, and link text that describes its destination. The visual order and reading order should agree. A screen reader or keyboard user should not encounter a different story from the one shown on screen.
Every interactive control should be reachable and usable with a keyboard. Focus must remain visible, menus and dialogs need predictable behavior, and no element should trap the user. Skip links help repeated navigation, but they do not repair a confused document structure.
- Tab through the page from the address bar to the footer.
- Confirm the focus indicator is visible against every background.
- Operate menus, accordions, dialogs, forms, media, and booking without a mouse.
- Check that focus moves intentionally after opening, closing, or submitting.
Make information perceivable in more than one way.
Text needs sufficient contrast and should not rely on color alone to communicate status. Users should be able to zoom or enlarge text without losing content or actions. Motion needs a reduced option when it is not essential.
Write alt text for informative images based on their purpose in context. Decorative images should be ignored by assistive technology. Caption videos when speech or meaningful sound carries information, and provide a transcript when it helps people consume or search the material.
- Contrast checked for text, controls, focus, and errors
- Meaning remains clear in grayscale and without icons
- Text enlargement and narrow reflow tested
- Useful alt text, captions, and transcripts present where needed
Forms must explain themselves before and after an error.
Give every input a programmatic label. State required formats and constraints before submission. When validation fails, identify the field, explain the problem in text, preserve valid input, and make the error available to assistive technology.
Do not use placeholder text as the only label. Do not use color as the only error cue. For important transactions, give the person a chance to review, correct, and confirm the information before it becomes final.
Combine automated, manual, and user testing.
Automated tools are efficient for certain code and contrast defects, but they cannot judge whether alt text is useful, headings tell a coherent story, or an error makes sense. Add manual keyboard, zoom, screen-reader, and task checks.
Keep an accessibility issue log with route, component, impact, evidence, owner, and retest result. Re-run the checks when templates, navigation, forms, colors, video, third-party widgets, or content rules change.
- Automated scan across representative templates
- Keyboard-only completion of every critical task
- Screen-reader spot checks on structure, controls, errors, and dynamic updates
- Zoom, text spacing, contrast, reflow, and reduced-motion checks
- Testing by people with disabilities when the risk and reach justify it
Questions
What buyers usually ask next.
Does the ADA apply to small-business websites?
The U.S. Department of Justice says Title III applies to businesses open to the public and that their online goods and services must be accessible. The exact legal analysis depends on the business and facts, so use qualified counsel for a legal conclusion.
What is WCAG 2.2?
WCAG 2.2 is a W3C web accessibility standard with testable success criteria organized around perceivable, operable, understandable, and robust content. W3C advises its use to maximize future applicability.
Can an automated accessibility scanner approve a website?
No single scanner can evaluate every requirement or real task. Use automated checks for what they can detect, then add keyboard, zoom, screen-reader, content, error, and human usability testing.
Is an accessibility widget enough?
A widget cannot replace fixing the underlying structure, labels, keyboard behavior, contrast, content, media, and form errors. Evaluate any added tool as one component, not as proof that the site is accessible.
References
Official sources used for factual claims.
Advice and checklists are Parcha Lab's original synthesis. Changeable technical, platform, standards, and legal-context facts are grounded in the primary sources below.
- U.S. Department of Justice Guidance on Web Accessibility and the ADA
- W3C Web Accessibility Initiative How to Meet WCAG 2.2