Website Accessibility Checklist for Sri Lankan Businesses

An accessible website allows more people to perceive, understand, navigate, and operate its content, including people with visual, hearing, motor, speech, cognitive, or neurological disabilities. Accessibility also helps older users, people with temporary injuries, slow connections, small screens, and difficult environments.

The W3C recommends using the current Web Content Accessibility Guidelines (WCAG) 2.2 to maximise future applicability. WCAG is organised around content being perceivable, operable, understandable, and robust. Legal obligations vary, so obtain qualified advice for the organisation and market; this article is an implementation checklist, not legal advice.

Establish an accessibility target

Name the standard and conformance level expected, priority user journeys, supported technologies, review owner, and evidence required. WCAG 2.2 Level AA is a common project target, but the exact obligation should be confirmed for the context.

Include accessibility in procurement, content templates, design reviews, acceptance criteria, and maintenance. Retrofitting a completed interface is slower and more expensive than making decisions early in website development.

Test keyboard operation

Use the site without a mouse. Every interactive control should be reachable and operable in a logical order. Focus must be visible, not trapped inside a modal or menu, and returned sensibly when a temporary component closes.

Provide a way to skip repeated navigation. Avoid creating clickable div or span elements when a native link, button, input, or disclosure control provides built-in semantics and keyboard behaviour. Ensure custom components match the expected interaction pattern.

Test menus, carousels, filters, dialogs, date pickers, checkout, consent, chat, and advertising placements—not only text pages.

Use clear structure and language

Each page needs a descriptive title and logical main heading. Heading levels should represent structure rather than visual size. Landmarks for header, navigation, main content, and footer help assistive-technology users move efficiently.

Set the document language and identify passages in another language when supported. Write concise instructions and descriptive link text. “View mobile app pricing” is more useful than several links labelled “click here.”

For sites in English, Sinhala, and Tamil, combine this checklist with the multilingual website planning guide.

Check colour, text, and resizing

Meet contrast requirements for text, essential icons, controls, and focus indicators. Do not use colour alone to communicate error, selection, or status. Test forced-colour or high-contrast settings where relevant.

Zoom and resize text. Content should reflow without sideways scrolling for ordinary reading, controls should remain available, and text should not be clipped. Avoid fixed-height containers that break when text grows. Keep line length and spacing comfortable without preventing user overrides.

Give images and media useful alternatives

Write alternative text that communicates the purpose of informative images. Use empty alternative text for genuinely decorative images so screen readers can skip them. Complex charts may need a nearby explanation or data table.

Provide captions for prerecorded video with speech and appropriate transcripts or audio description according to the content and target. Avoid autoplaying sound. Give users control over motion, animation, carousels, and time limits.

Generated or stock imagery should not be the only evidence for a real person, office, product, or outcome. Keep visual claims honest.

Make forms understandable

Every input needs a persistent programmatic label. Group related choices, explain formats before submission, and identify required fields without relying only on colour. Error messages should describe the field and correction, and focus should move or be announced appropriately.

Preserve valid entries after an error. Allow review before consequential submission. Authentication should support accessible recovery and should not require a cognitive puzzle without an alternative.

Test checkout and payment errors using the e-commerce payment guide, where third-party components also need review.

Test responsive and touch use

Use real phones, portrait and landscape orientation, large text settings, screen readers, and switch or voice input where appropriate. Touch targets should be sufficiently large and separated. Important actions should not depend only on hover, precise dragging, multi-finger gestures, or device motion.

Keep overlays from covering content and allow users to dismiss them. Reserve space for images and ads to reduce unexpected movement. The Core Web Vitals guide complements accessibility by addressing loading, responsiveness, and stability.

Combine tools with human review

Automated tools find some contrast, naming, and markup failures, but they cannot decide whether text is clear, alternative text is useful, focus order makes sense, or a workflow is usable. Add manual keyboard and screen-reader review, code inspection, and testing with disabled people who represent priority journeys.

Record each issue with page, component, standard reference, severity, user impact, owner, fix, and retest evidence. Fix shared components first because one change can improve many pages.

Publish an accessible contact route for feedback and assign a response process. Re-test after design-system, framework, content, or third-party changes. To include accessibility in a redesign, follow the website redesign checklist, review website services, or share the priority journeys through Get Started.