Home › Web Design › Website Accessibility
WEBSITE ACCESSIBILITY
Website Accessibility: Principles, WCAG, UX & Best Practices
Accessible websites are built so that more people can perceive, understand, navigate and interact with content — whatever device, input method or assistive technology they use.
This guide covers accessibility end to end: WCAG and the POUR principles, semantic HTML, keyboard access and focus, screen readers, colour and contrast, forms, multimedia, motion, mobile and touch, ARIA, testing and audits, and how all of it applies in Elementor.
- WCAG explained without jargon or legal claims
- Practical patterns for forms, focus and navigation
- Testing methods and an honest view of their limits
THE BASICS
What Is Website Accessibility?
Website accessibility means designing and building websites so people with different abilities can perceive, understand, navigate and interact with the content. It’s a property of how a site is made, not a feature added to it.
It matters for people with visual, hearing, motor, cognitive and speech-related disabilities — and for the much larger group experiencing temporary or situational limitations. Someone with a broken arm navigating one-handed, a person in bright sunlight, a visitor in a noisy room without headphones, someone on a slow connection, or anyone using a touchscreen instead of a mouse all benefit from the same work.
Accessibility runs through design, content, HTML, CSS, JavaScript, interaction patterns, assistive technology support, testing and ongoing maintenance. No single plugin, widget or overlay covers all of that.
Accessibility spans
- Visual design and contrast
- Content and plain language
- Semantic HTML structure
- Keyboard and focus behaviour
- Assistive technology support
- Responsive and touch interaction
- Testing and maintenance
WHY IT MATTERS
Why Is Website Accessibility Important?
Accessibility is far cheaper to design in than to retrofit. Choosing accessible colour pairs or planning focus states during design costs almost nothing; rebuilding a finished interface costs a great deal.
Inclusive Access
More people can use your content, including those relying on assistive technology.
Better Usability
Clear structure, labels and feedback help everyone, not only some visitors.
Keyboard Support
Supports people who can't or don't use a mouse, including power users.
Assistive Technology
Lets screen readers and similar tools interpret content meaningfully.
Mobile Usability
Touch targets, readable text and reflow benefit mobile visitors too.
Content Clarity
Clear labels, headings and instructions reduce confusion for all readers.
RELATED DISCIPLINES
Website Accessibility and Inclusive Design
The two overlap but aren’t the same. Inclusive design is a broad approach that considers the range of people who might use something and the situations they’re in. Accessibility focuses on removing barriers for people with disabilities and supporting assistive technologies, with testable criteria behind it.
Inclusive thinking without accessibility practice can miss concrete requirements; accessibility work without inclusive thinking can become box-ticking. Most good teams use both.
WCAG
What Is WCAG and What Are the POUR Principles?
WCAG stands for the Web Content Accessibility Guidelines, published by the W3C’s Web Accessibility Initiative and used internationally as the technical reference for web accessibility. It’s organised around four principles — often remembered as POUR — each containing guidelines and specific, testable success criteria.
Perceivable
Information and interface components must be presented in ways people can perceive — through text alternatives, captions, adaptable structure and sufficient contrast.
Operable
Interface components and navigation must be operable, including by keyboard, with enough time and without content that causes seizures.
Understandable
Content and interface behaviour must be understandable: readable text, predictable interactions and help with avoiding and correcting mistakes.
Robust
Content must work reliably with current and future user agents, including assistive technologies — which in practice means valid, semantic markup.
Conformance levels: A, AA, AAA
WCAG success criteria are grouped into three conformance levels. A covers the most basic requirements, AA adds criteria addressing common significant barriers, and AAA includes the most demanding criteria, which aren’t achievable for all content types.
AA is the level most commonly referenced in accessibility policies and procurement requirements. What actually applies to a given site depends on jurisdiction, sector, organisational policy and the services offered.
Success criteria, not scores
Each criterion is a specific, testable statement — about text alternatives, keyboard operation, contrast, focus visibility and so on. Evaluating accessibility means checking individual criteria against real content, not reading a single percentage from a tool.
WCAG is detailed and evolves over time. For definitions, current versions and the full list of criteria, use the official source: W3C Web Accessibility Initiative — WCAG.
One caution worth stating plainly: this page is educational, not legal advice. Accessibility obligations vary by jurisdiction, industry and organisation. WCAG is an important technical standard, but legal questions should be assessed with appropriate professional guidance.
PERCEIVABLE
Perceivable Content and Accessible Images
Perceivable content means information is available through more than one channel. Images need text alternatives, video needs captions, audio needs transcripts, and information shouldn’t depend on a single sense or presentation method.
Alt text describes an image’s purpose in its context. An informative image gets a description of what it conveys — “Website navigation tree showing main categories and subcategories.” A functional image, such as an icon inside a button, is described by its action: “Search”. A decorative image that adds nothing to understanding should be hidden from assistive technology with an empty alt attribute, rather than given a description nobody needs.
Never keyword-stuff alt text. Something like “best website accessibility website design Pune” helps nobody and actively degrades the experience for screen-reader users. Also avoid putting essential information only inside an image — text in images can’t be resized, translated or read aloud reliably. Complex diagrams usually need a longer description nearby.
Choosing alt text
alt="..."alt="Search"alt=""figure—COLOUR
Colour and Contrast in Accessible Design
Two separate rules do most of the work. First, colour must never be the only way information is conveyed. Red for an error and green for success are invisible distinctions to some people — pair colour with text, an icon or a shape so the meaning survives without it.
Second, there must be sufficient contrast between text and its background, and between meaningful interface elements and theirs: buttons, icons, form control borders and focus indicators all count. Requirements differ by text size and element type, and WCAG defines specific minimum ratios — check the current values in the official WCAG documentation rather than relying on numbers quoted second-hand.
Don’t judge contrast by eye. Palettes that look bold can fail, particularly light grey on white and mid-tone text on coloured backgrounds. Use a contrast checker on the actual values.
STRUCTURE
Accessible Typography, Headings and Semantic HTML
Readable text needs comfortable sizes, generous line height, sensible line length and adequate contrast. People must be able to zoom and have content reflow into a single column without losing information or functionality — both are explicit WCAG concerns, and both are where fixed-height containers cause trouble.
Headings convey structure, not size. Choose the level that reflects the content’s place in the hierarchy and style it separately. Screen-reader users routinely navigate by heading, so a page whose headings jump from H1 to H4 because H4 looked right is genuinely harder to use.
The same logic applies to semantic HTML generally. Elements such as header, nav, main, section, article, footer, button, a, form and label describe what content is, giving browsers and assistive technologies meaning that a styled div can never provide. Visual design plus semantic structure is what makes an interface understandable to both people and machines.
H2 — Major section
H3 — Subsection
H3 — Subsection
H2 — Next major section
ELEMENT CHOICE
Buttons and Links: Use the Right Element
Choosing the correct element gives you keyboard behaviour, focus handling and assistive-technology announcements for free. Recreate a button from a div and you inherit none of it — you have to rebuild tab order, key handling and role announcement by hand, and most implementations miss something.
<nav aria-label="Primary"> … </nav> <button type="button">Open menu</button> <label for="email">Email address</label> <input id="email" type="email" autocomplete="email"> <a href="/web-design/website-navigation/">Website Navigation guide</a>
KEYBOARD
Keyboard Accessibility, Focus and Skip Links
Everything interactive must work without a mouse. Tab and Shift + Tab move between controls, Enter activates links and buttons, Space activates buttons and checkboxes, Escape closes menus and dialogs, and arrow keys move within composite widgets such as tab sets.
Visible focus is essential: keyboard users need to see where they are. Removing focus outlines because they look untidy is one of the most damaging small decisions in web design. If the default outline doesn’t suit the design, replace it with something equally visible, not with nothing.
Focus order should follow a meaningful sequence, usually matching the visual reading order. Unexpected jumps — or focus that gets trapped inside a component with no way out — make interfaces unusable. A skip link at the top of the page lets keyboard users bypass repeated navigation and go straight to the main content; it’s typically hidden until focused, and one per page is enough.
ASSISTIVE TECHNOLOGY
Screen Readers and Page Landmarks
A screen reader converts interface content into speech or braille and lets people navigate by structure — jumping between headings, landmarks, links, buttons and form fields rather than reading everything in order. That’s why headings, labels, alt text, meaningful link text, a descriptive page title and a sensible reading order matter so much.
Landmarks come from semantic elements: header as banner, nav for navigation, main for the primary content, aside as complementary and footer as content info. They let someone move straight to the part of the page they want. Where a page has several navigation regions, giving each an accessible name distinguishes them.
Screen readers differ in behaviour and combine differently with each browser, so don’t design for one product. And a page being readable by a screen reader is not the same as being accessible — it can still have poor contrast, keyboard traps or incomprehensible content.
sourceh1–h6nav / mainnamelabeloutputNAVIGATION
Accessible Navigation, Dropdowns and Mega Menus
Navigation is where accessibility failures hurt most, because an inoperable menu blocks the whole site. Menus need full keyboard operation, clear labels, a visible current-page state, visible focus, announced expanded and collapsed states, and an accessible name on any icon-only toggle such as a hamburger button.
Dropdowns and mega menus must not depend on hover alone — touch devices have no hover, and keyboard users never trigger it. Submenus should open by click or keypress, close on Escape, return focus to the control that opened them, and keep focus inside while open where that’s the intended pattern. Large mega menus need particular care: dozens of links in a panel can be slow to traverse, so grouping with headings helps.
More on structure and patterns in our website navigation guide.
Menu accessibility checks
- Operable by keyboard alone
- Opens on click or keypress, not hover only
- Escape closes and returns focus
- Expanded state is announced
- Icon-only toggles have accessible names
- Current section is visible
- Touch targets are comfortable
FORMS
Accessible Forms, Labels, Errors and Required Fields
Every field needs a visible label that is also programmatically associated with its input. Placeholder text is not a label: it disappears the moment someone types, often has poor contrast, and isn’t reliably announced. Use both if you like, but never the placeholder alone.
Required fields should be identifiable in more than one way — the word “required” in the label alongside any asterisk, plus the appropriate attribute so assistive technology announces it. An asterisk in red is exactly the colour-only cue to avoid.
Error messages must say what went wrong and how to fix it, sit next to the field concerned, be identifiable without relying on colour, and be conveyed to assistive technology when they appear. “Invalid” tells nobody anything. Preserve what people already typed, group related fields with clear instructions, choose appropriate input types, and use autocomplete attributes where they help. Confirm success explicitly.
LABELS
Accessible Button and Link Text
Controls must say what they do. Screen-reader users often pull up a list of links or buttons out of context, so text that only makes sense alongside surrounding copy becomes useless. Buttons also need sufficient contrast, visible focus, comfortable touch targets and clear state feedback.
Weaker labels
- Click here
- Read more
- Submit
- Learn more (repeated ten times)
- An icon button with no accessible name
Clearer labels
- Read the Website Navigation guide
- Download the accessibility checklist
- Send message
- View responsive design examples
- Close dialog
If a design calls for short repeated link text, ensure the accessible name still distinguishes destinations. Several identical “Read more” links in one page force people to guess.
MEDIA
Multimedia, Motion and Carousels
Captions and Transcripts
Captions present spoken content and relevant sounds synchronised with video, supporting people who are deaf or hard of hearing and anyone watching without sound. A transcript is a text version of the whole thing, useful for reading, searching and skimming. Audio descriptions convey important visual information for people who can't see it. Prerecorded and live content have different requirements, so what's needed depends on the material.
Audio and Players
Audio content needs a transcript. Players need accessible, keyboard-operable controls with clear labels, and volume control. Avoid unexpected autoplay: sound starting without warning disrupts screen-reader users particularly badly, and anything playing longer than a few seconds should be pausable.
Motion and Carousels
Excessive animation, parallax and motion-triggered effects can cause discomfort or nausea for people sensitive to movement. Honour the prefers-reduced-motion setting rather than removing all animation. Carousels need keyboard controls, a visible pause, clear labels and current-slide state — auto-advancing content that can't be stopped is a barrier.
MOBILE & TOUCH
Mobile, Touch and Responsive Accessibility
Mobile accessibility isn’t desktop accessibility at a narrower width. Content must remain usable when zoomed and when text is scaled up in system settings, work in both orientations, and reflow into one column without losing content or functionality. Mobile screen readers add their own gesture-based navigation that depends on the same semantic structure.
For touch, targets need adequate size and, just as importantly, spacing so neighbouring controls aren’t triggered by accident. Anything that works only through a complex gesture — a drag, a pinch, a multi-finger swipe — needs a simpler alternative such as a button, since not everyone can perform precise gestures.
Responsive layouts should preserve content, structure, functionality, readability, navigation and focus behaviour at every size. Nothing important should be hidden on small screens simply because it doesn’t fit. See responsive design.
Mobile accessibility checks
- Content usable at increased zoom
- Respects system text scaling
- Works in both orientations
- Reflows without losing content
- Comfortable touch target spacing
- Alternatives to complex gestures
- Focus visible on touch devices too
UNDERSTANDABLE
Cognitive Accessibility, Clear Language and Error Prevention
Cognitive Accessibility
Predictable navigation, consistent layouts, clear instructions, manageable amounts of information at once and helpful feedback all reduce the effort of using a site. Avoid unnecessary complexity, timeouts that can't be extended and interfaces that change unexpectedly while someone is using them.
Clear Language
Plain language, short paragraphs, descriptive headings, lists for grouped points and familiar terms make content easier to follow. Explain jargon the first time it appears. Readability should suit the audience and subject — technical content can still be clearly written.
Error Prevention
Prevent mistakes where you can: sensible input formats, clear instructions before the field, and confirmation before consequential or irreversible actions. When something does go wrong, preserve entered data and make recovery obvious. Not every action needs a confirmation step — overusing them creates its own friction.
ARIA
ARIA: What It Is and When to Use It
ARIA stands for Accessible Rich Internet Applications. It’s a set of roles, states and properties that supply accessibility information for custom components HTML has no native element for — tab sets, comboboxes, complex widgets.
The governing principle is to prefer native semantic HTML whenever it already does the job. A button arrives with keyboard activation, focusability and the right role; a div with role="button" has the role and nothing else. ARIA changes how something is announced — it never adds behaviour, focus handling or visual states.
Common mistakes follow from forgetting that: adding ARIA that duplicates native semantics, using incorrect roles, letting states such as aria-expanded drift out of sync with reality, breaking relationships with ids that don’t match, and building custom controls that announce correctly but can’t be operated by keyboard. Incorrect ARIA is often worse than none, because it makes confident but false promises. Always test the result with assistive technology.
<!-- Native: keyboard and role built in --> <button type="button" aria-expanded="false">Menu</button> <!-- Avoid: no keyboard behaviour, no role --> <div class="button">Menu</div>
TESTING
How to Test Website Accessibility
Reliable testing layers several methods, because each finds different problems. No single approach — and certainly no single score — tells you whether a site is accessible.
Automated testing
Scanners quickly flag missing alt attributes, missing form labels, some contrast failures, certain structural problems and some ARIA errors across many pages.
- Whether alt text is meaningful
- Whether content is understandable
- Whether navigation makes sense
- Whether a task can be completed
- Whether custom interactions behave predictably
The list above is what automated tools cannot reliably judge.
Manual testing
Human checks catch what tooling can’t. Work through the page deliberately:
- Keyboard-only walkthrough
- Zoom and text-scaling test
- Focus visibility and order
- Heading structure review
- Link and button text review
- Form and error review
- Navigation and landmark review
- Contrast spot checks
- Content clarity review
- Responsive review
Assistive technology testing
Testing with a screen reader reveals issues with heading structure, labels, button and link names, landmarks, reading order and whether dynamic updates are announced.
Behaviour differs between screen readers and browser combinations, so don’t treat one product as representative. Where possible, testing with people who use assistive technology daily is more informative than any checklist — they use it fluently, which tooling and occasional testers don’t.
AUDIT
Website Accessibility Audit and Issue Prioritisation
An audit is a process, not a score. It documents specific issues against specific criteria, with enough detail for someone to fix them — which is why the output looks like the table below rather than a percentage.
Review Scope
Identify key pages, templates and user tasks.
Automated Scan
Catch common, machine-detectable issues at scale.
Keyboard Testing
Walk every interactive element without a mouse.
Manual Review
Check structure, labels, content and contrast.
Assistive Technology
Test with at least one screen reader.
Prioritise Issues
Weigh severity, frequency and task importance.
Fix
Address causes, not only symptoms.
Retest
Confirm fixes work and nothing regressed.
| Review area | Example issue | Status | Recommended action |
|---|---|---|---|
| Structure | Heading levels skipped | To review | Reassign levels to match hierarchy |
| Keyboard | Menu not operable by keyboard | To fix | Add click and key handling |
| Forms | Placeholder used as label | To fix | Add visible associated labels |
| Images | Decorative image described | To review | Use empty alt attribute |
| Colour | Status shown by colour only | To fix | Add text or icon cue |
| Multimedia | Video without captions | To review | Add captions and transcript |
Prioritise by severity (does it block a task entirely?), frequency (is it in a template repeated site-wide?), how many people are affected, how important the task is, and how easily it can be remedied. Fixing a broken keyboard path on a checkout matters more than a marginal contrast issue in a footer. Resist arbitrary scoring systems — they flatten exactly the judgement that matters.
TOOLING
Website Accessibility Testing Tools
Tool categories rather than rankings. No tool guarantees accessibility or legal compliance, and an accessibility overlay or widget is not a substitute for accessible design and markup — it can’t fix the underlying structure it sits on top of.
Automated Scanners
Check pages or whole sites for machine-detectable issues.
Browser Developer Tools
Inspect markup, focus order and computed styles.
Contrast Checkers
Test specific colour pairs against WCAG criteria.
Keyboard Testing
No tool needed — the Tab key and your own attention.
Screen Readers
Desktop and mobile screen readers for real-world checks.
Accessibility Tree Inspectors
See how a page is exposed to assistive technology.
Audit-Style Reports
Lighthouse-style audits covering some accessibility checks.
Responsive Testing
Check zoom, reflow and text scaling behaviour.
IMPROVEMENTS
Common Accessibility Improvements
Most accessibility work is small, specific changes like these. Each removes a real barrier — none of them, alone or together, makes a site accessible on its own.
Before
- Button has an unclear label
- Form uses placeholder text only
- Error shown only in red
- Dropdown opens on hover only
- Icon button with no name
- Focus outline removed
After
- Button reads “Submit contact form”
- Visible label associated with the input
- Colour plus text, tied to the field
- Opens by click and keyboard, closes on Escape
- Icon button with an accessible name
- Custom focus style, equally visible
PITFALLS
Common Website Accessibility Mistakes to Avoid
Missing Image Alternatives
Meaningful images without alt text leave gaps in the content.
Poor Colour Contrast
Low-contrast text excludes many readers, not only some.
Using Colour Alone
Meaning disappears for anyone who can't distinguish the colours.
Missing Form Labels
Fields without labels are guesswork for assistive technology users.
Placeholder-Only Forms
The hint vanishes as soon as typing begins.
Invisible Focus States
Keyboard users lose track of where they are.
Keyboard Traps
Focus enters a component and can't leave.
Mouse-Only Interaction
Hover or drag-only controls exclude keyboard and touch users.
Poor Heading Structure
Levels chosen for size break navigation by heading.
Unclear Link Text
“Click here” means nothing out of context.
Inaccessible Dropdowns
Menus that need hover or a mouse to operate.
Uncaptioned Videos
Spoken content unavailable to many viewers.
Excessive Motion
Animation that causes discomfort or hides content.
Incorrect ARIA
Wrong roles and stale states mislead assistive technology.
Tiny Touch Targets
Controls too small or close together to hit reliably.
Poor Mobile Accessibility
Layouts that break under zoom or text scaling.
Unclear Error Messages
“Invalid” offers no route to recovery.
Testing Only at the End
Late discovery means expensive rework.
Relying Only on Automated Tools
Scanners catch a fraction of real barriers.
Treating a Widget as a Solution
Overlays don't fix underlying structure or markup.
WORKFLOW
How to Make a Website More Accessible
Accessibility belongs at every stage, not in a pre-launch sprint. Each new feature, template and content update can introduce barriers, which is why the last step is maintenance rather than completion.
Understand Users
Identify different needs, devices and contexts.
Plan Accessible Structure
Start with logical content and navigation.
Use Semantic HTML
Choose elements by meaning, not appearance.
Design Accessible UI
Contrast, typography, focus and interaction states.
Build Keyboard Support
Make everything operable without a mouse.
Create Accessible Forms
Labels, instructions and understandable errors.
Provide Alternatives
Alt text, captions and transcripts where needed.
Test
Combine automated, manual and assistive technology methods.
Fix Issues
Prioritise the barriers that block real tasks.
Retest and Maintain
Accessibility continues after launch.
CONNECTIONS
How Accessibility Connects to the Rest of Design
UI/UX Design
Accessibility and UX overlap heavily — clear hierarchy, predictable interaction, good feedback and readable content serve both — but they aren't the same. UX can be excellent for most users while excluding some. See UI/UX design.
Website Design Basics
Typography, colour, spacing, layout and content hierarchy are where most accessibility is decided. See website design basics.
Landing Pages
Focused pages still need accessible headings, CTA labels, keyboard access, form labels, contrast, alt text and captions. See landing page design.
Performance
Fewer unnecessary scripts, optimised images, efficient layouts and restrained animation help both areas — but a fast site isn't automatically accessible. See website speed.
SEO
Semantic headings, descriptive links, text alternatives, logical structure and crawlable links serve both. They share techniques, not goals — and accessibility is not a ranking guarantee. See website SEO.
Design Trends
New patterns should be judged against usability and accessibility rather than adopted because they look current. See website design trends.
ELEMENTOR
Website Accessibility in Elementor
Elementor gives you control over most of what matters, provided you use it deliberately. Set heading tags by meaning and adjust size separately. Build with containers so the content order in the markup matches the visual order — reordering visually on one breakpoint without considering the underlying order can scramble the keyboard and reading sequence.
Give buttons and links descriptive text, add alt text on informative images, use form widget labels rather than placeholders alone, and check global colours for contrast. Interactive widgets — accordions, tabs, sliders, pop-ups — vary in how well they handle keyboard and focus, so test each one you use. Custom CSS can restore a visible focus style if a theme removes it. Interface labels shift between versions, so treat these as concepts rather than menu paths.
Widgets worth testing individually
- Menus and mobile toggles
- Accordions and tabs
- Sliders and carousels
- Pop-ups and dialogs
- Forms and validation messages
- Anything with hover-triggered content
ELEMENTOR PRACTICE
Elementor Accessibility Best Practices
Use Correct Heading Structure
Choose heading levels by meaning, then style them; don't pick H3 because it looked the right size.
Use Descriptive Link Text
Make each link's destination clear on its own.
Use Proper Button Labels
Say what the action does, and give icon-only buttons accessible names.
Add Meaningful Alt Text
Describe informative images; leave decorative ones empty.
Check Contrast
Test global colours against real backgrounds, including buttons.
Test Keyboard Access
Tab through menus, sliders, tabs and pop-ups.
Review Forms
Use visible labels, clear required indicators and specific errors.
Check Responsive Behaviour
Confirm accessibility holds under zoom and at every breakpoint.
Test After Publishing
The editor preview doesn't represent every visitor's experience.
PRINCIPLES
Accessibility Design Principles
Perceivable
Information is available through more than one channel.
Operable
Everything works with appropriate input methods.
Understandable
Content and behaviour are clear and predictable.
Robust
Content works across browsers and assistive technologies.
Semantic
Markup describes meaning, not just appearance.
Keyboard Friendly
No functionality depends on a mouse.
Responsive
Accessibility holds at every screen size and zoom level.
Tested
Automated, manual and assistive technology testing combined.
CHECKLIST
Website Accessibility Checklist
A structured review list covering content, structure, interaction, media and testing. It is a working tool, not a certification or a statement of conformance — passing every line does not establish WCAG conformance or legal compliance.
- Page has a clear title
- Page has one meaningful H1
- Headings follow a logical hierarchy
- Navigation is understandable
- Keyboard access works throughout
- Focus is visible
- Skip link available where appropriate
- Links have meaningful text
- Buttons have clear labels
- Forms have proper labels
- Required fields are identifiable
- Errors are understandable
- Images have appropriate alternatives
- Decorative images handled appropriately
- Colour is not the only information cue
- Text has sufficient contrast
- Content remains usable when zoomed
- Layout works on mobile
- Videos have appropriate captions
- Audio has appropriate alternatives
- Animation is handled responsibly
- Interactive components have accessible states
- Navigation works without a mouse
- Automated testing supplemented with manual testing
- Issues retested after fixes
[ ] Page has a clear title [ ] Page has one meaningful H1 [ ] Headings follow a logical hierarchy [ ] Navigation is understandable [ ] Keyboard access works throughout [ ] Focus is visible [ ] Skip link available where appropriate [ ] Links have meaningful text [ ] Buttons have clear labels [ ] Forms have proper labels [ ] Required fields are identifiable [ ] Errors are understandable [ ] Images have appropriate alternatives [ ] Decorative images handled appropriately [ ] Colour is not the only information cue [ ] Text has sufficient contrast [ ] Content remains usable when zoomed [ ] Layout works on mobile [ ] Videos have appropriate captions [ ] Audio has appropriate alternatives [ ] Animation is handled responsibly [ ] Interactive components have accessible states [ ] Navigation works without a mouse [ ] Automated testing supplemented with manual testing [ ] Issues retested after fixes
NEXT TOPICS
Continue Learning Website Design
Website Design Basics
Learn the foundations of layout, typography, colour, spacing and content hierarchy.
UI/UX Design
Learn how interface and experience decisions affect usability and accessibility.
Responsive Design
Learn how websites adapt across devices while staying usable.
Landing Pages
Learn how to build focused pages with accessible content, forms and CTAs.
Website Navigation
Learn how to create clear, keyboard-friendly and responsive navigation.
Website Design Trends
Explore current patterns and evaluate their usability and accessibility implications.
FAQ
Website Accessibility: Frequently Asked Questions
Short answers to the questions people ask most about accessible web design.
Build More Accessible Website Experiences
Learn how to design website structures, interfaces, forms, navigation and responsive experiences that are easier for more people to perceive, understand and use.