Web Accessibility: The Minimum That Isn't Optional
Accessibility is treated as a specialist concern and is mostly not one. A handful of decisions cover the majority of real-world barriers, they cost almost nothing when built in, and they improve the site for everyone — not only for people using assistive technology.
Here is the practical minimum. For remote production teams, a related reference is further reading, which looks at how activity signals should be interpreted.
Colour contrast
The most common failure, and the easiest to fix.
Targets: at least 4.5:1 for body text against its background, and 3:1 for large text (roughly 24px, or 19px bold) and for meaningful interface elements like icons and input borders.
Light grey on white fails. So does most placeholder text, most disabled-state styling, and a great many brand palettes used at their natural values. Security reviews should also account for the OWASP Top 10.
Never use colour alone to convey information. A red border on an invalid form field is invisible to a significant share of users. Pair it with an icon and a text message.
Check with any contrast checker during design, not after build.
Keyboard navigation
Everything achievable with a mouse must be achievable with a keyboard.
Test it yourself in five minutes: put the mouse aside and navigate your site with Tab, Shift+Tab, Enter, Space, and the arrow keys.
What to check:. For search implementation details, consult the Google Search Central documentation.
- Every link, button, form field, and control is reachable
- The focus indicator is visible — never remove focus outlines without replacing them with something clearer
- Tab order follows the visual order
- Modals trap focus while open and return it on close
- Dropdowns and menus operate without hover
- A "skip to content" link lets users bypass the navigation
Custom components are where this breaks. A div styled as a button is not a button — it is not focusable, does not respond to Enter, and is not announced as interactive. Use real <button> and <a> elements.
Alt text
Every image needs an alt attribute. What goes in it depends on the image's role.
Informative images: describe the content. "Bar chart showing revenue growing from AED 2M to AED 5M between 2023 and 2026."
Decorative images: empty alt, alt="". This tells screen readers to skip it. Omitting the attribute entirely is different and worse — the file name gets read out.
Images that are links: describe the destination, not the picture.
Text in images: the alt must contain the text. Better still, do not put text in images.
Avoid "image of" and "picture of" — screen readers already announce that it is an image.
Headings
Headings are a navigation structure, not a set of font sizes.
- One
<h1>per page, describing the page - Levels descend in order — no jumping from
<h2>to<h4> - Use headings for structure; use CSS for size
Screen reader users navigate by heading, jumping between them to find sections. A page where headings were chosen for visual weight is a page with a scrambled table of contents.
Forms
- Every field has a
<label>, properly associated. Placeholder text is not a label — it disappears on focus and fails contrast - Error messages are specific and adjacent to the field: "Enter an email address including @", not "Invalid input"
- Errors are announced, not only shown in colour
- Required fields are marked in text, not by an asterisk alone
- Groups of related fields use
<fieldset>and<legend> - Nothing times out without warning and an option to extend
Other essentials
Page language. <html lang="en">, or the appropriate value. Screen readers use it to select pronunciation, and it must change on pages in another language.
Link text that makes sense alone. "Read more" repeated fifteen times tells a user navigating by link nothing. "Read our guide to logo file formats" does.
Video captions, and transcripts for audio.
No autoplay with sound.
Nothing flashing more than three times per second.
Respect reduced motion. Honour the prefers-reduced-motion setting and disable non-essential animation for users who have asked for it.
Zoom to 200% without loss of content or function.
What to put in a brief
The site must conform to WCAG 2.2 Level AA. Deliverables include an accessibility audit report and remediation of any issues identified before final acceptance.
WCAG 2.2 Level AA is the standard most regulations and procurement processes reference. Specifying it in writing turns accessibility from a favour into a requirement.
Also ask for accessibility to be part of design review, not a post-build audit. Contrast failures and unusable custom components are cheap to prevent and expensive to retrofit.
Automated tools and their limits
Browser extensions and CLI tools — axe, Lighthouse, WAVE — catch mechanical failures fast: missing alt attributes, contrast violations, unlabelled inputs, heading order problems.
They detect roughly a third of real issues. They cannot tell you whether alt text is meaningful, whether tab order makes sense, whether an error message is comprehensible, or whether a custom component behaves correctly.
Run them, fix what they find, then test manually with a keyboard. That combination covers most of what matters without specialist expertise.
Why this pays for itself
Accessible sites are better sites, and the overlap is not coincidental.
Good contrast helps anyone on a phone in sunlight. Clear labels reduce form abandonment. Proper heading structure helps search engines parse your content. Captions serve people watching without sound in a public place. Keyboard support helps power users.
The share of users with a disability affecting web use is substantial in any market, and the accommodations are largely the same accommodations that make an interface work under ordinary imperfect conditions.
Закладываем доступность в дизайн-этап, а не правим после сборки. Услуги веб-дизайна. .