Web accessibility (WCAG) guide: why it matters and how to apply it

Web accessibility means a site can be used by everyone, including people with visual, hearing, motor or cognitive differences, and its international reference is WCAG. In practice, sufficient colour contrast, an interface that works with the keyboard alone, meaningful alternative text, labelled form fields and regular testing are the core steps for bringing an organisational site close to level AA. Handled at design stage, accessibility adds little cost; retrofitted later, it means rebuilding most components.

What is web accessibility and why does it matter?

Accessibility is often associated only with blind users, but its scope is much wider. Someone using a screen reader, someone who navigates by keyboard alone because they cannot use a mouse, someone with colour blindness, someone who cannot hear the speech in a video and someone who struggles to follow complex text are all users who meet different barriers on the same site. Vision and motor ability that decline with age belong on that list too.

Barriers are not always permanent either. Someone with an arm in a cast, someone looking at a phone in bright sunlight or someone watching a video in a noisy place experiences similar problems, temporarily or situationally. Accessible design is therefore not an adaptation for a particular minority but a quality standard that improves the experience of every user.

For organisations, accessibility also has a responsibility dimension. Public service bodies, educational institutions, associations and professional bodies are expected to offer their services equally to all their members and stakeholders. Because accessibility regulations can vary by country and type of organisation, current obligations should be checked against official sources; this article is not a substitute for legal assessment.

What is WCAG and which level should you aim for?

WCAG, the Web Content Accessibility Guidelines, is the international standard that defines how to make web content accessible. The guidelines consist of testable success criteria, each classified at level A, AA or AAA. A covers the most basic requirements, AA is the widely accepted target for organisational sites, and AAA is the most advanced level, which is not always achievable for every type of content.

All of WCAG's criteria are grouped around four principles. They offer a simple mental framework for assessing a site's accessibility.

• Perceivable: information and interface components are presented in ways users can perceive, for example text equivalents for images and captions for videos.
• Operable: every function can be used with a keyboard, and users are given enough time to read and use the content.
• Understandable: text is readable, the interface is predictable and form errors are explained clearly.
• Robust: content can be interpreted reliably by different assistive technologies, including screen readers.

The standard grows over time with new versions, and each version largely keeps the criteria of the previous one. For a new project, aiming for level AA of the current version meets today's expectations and gives a solid basis for future audits.

How do you ensure sufficient colour contrast?

Colour contrast is the difference in luminance between text and its background, and it is the most basic condition for readability. WCAG level AA requires a contrast ratio of at least 4.5:1 for normal-size text and at least 3:1 for large text. Non-text interface elements such as button borders, form field outlines and icons are also expected to reach at least 3:1. Light grey text and faded buttons may look elegant in a design, but they are the most common reason for falling below these thresholds.

Besides contrast, colour should never carry information on its own. Marking an invalid form field only with a red border, required fields only by colour or chart series only by colour difference makes the information invisible to users with colour blindness. Adding an icon, text or pattern alongside the colour solves the problem.

The most sustainable way is to make contrast decisions in the colour palette and design system rather than page by page. The ratio of each text and background pair is measured once when the palette is built, and components use only approved pairs. If the site has a dark theme, the same check has to be done separately for its colours.

How do you ensure and test keyboard use?

Users who cannot use a mouse, screen reader users and many people who simply prefer to work fast use sites with the keyboard. Every interactive element, including links, buttons, menus, pop-ups and form fields, must therefore be reachable and operable by keyboard. Using real button and link elements instead of plain boxes with click handlers attached meets most of this requirement automatically.

The most frequently neglected part of keyboard accessibility is the focus indicator. When the outline that shows which element the user is on is removed for visual reasons, keyboard users lose track of where they are on the page. The focus indicator should never be removed; if necessary, redesign it in a clear way that fits the site's visual language.

Keyboard testing needs no special tool. Putting the mouse aside and following the steps below reveals most of the critical problems within minutes.

• Move through the page from top to bottom with the Tab key and check that focus advances in a logical order.
• Make sure the focused element is clearly visible at every step.
• Confirm that a «skip to content» link at the top of the page jumps past the menu to the main content.
• Open and close drop-down menus and dialogs by keyboard, and check that focus returns to the right place when a dialog closes.
• Confirm that no element traps focus and stops the user from moving on.
• Fill in and submit forms using only the keyboard, and check that you can reach the error messages.

How do you write alternative text and form labels?

Alternative text is a short description that conveys an image's function and meaning to users who cannot see it. Good alternative text explains the image's purpose on the page rather than describing it. The alternative text for a congress poster should not be «poster» but the information the poster carries; for a logo used as a link, it should say where the link goes. For purely decorative images the alternative text is left empty, so screen readers skip them.

For complex images such as charts and tables, short alternative text is not enough; there should be text next to or below the image summarising what it shows. Link text should follow the same logic: screen reader users often listen to the links on a page as a list, and a series of «click here» phrases means nothing in that list.

Forms are where accessibility problems lose the most users, because when a membership application, congress registration or contact form cannot be completed, the user cannot get the job done. The following rules should apply to form fields.

• Every field has a visible label that is programmatically associated with it.
• Placeholder text inside a field is never used in place of a label, because it disappears once typing begins.
• Required fields are indicated in text, not only by colour.
• Error messages say clearly which field has what problem and how to fix it.
• When an error occurs, the user's input is not wiped and focus moves to the first invalid field.

Accessibility is not a feature added to a site afterwards; it is every component being built right from the start.

How do you test and maintain accessibility?

Automated testing tools quickly find problems such as missing alternative text, low contrast or unlabelled form fields, and they are a good starting point. But they can reliably check only part of the WCAG criteria. Only a person can judge whether alternative text is meaningful, whether the focus order makes sense or whether an error message is understandable.

A healthy testing process therefore has three layers: automated checks during development, manual keyboard and screen reader checks before release and, where possible, trials with real users of assistive technology. Screen readers come built into operating systems, and learning a few basic commands is enough to understand how a page reaches a screen reader user.

Accessibility has to be maintained after launch as well. Content editors learning to write alternative text, choose the right heading level and write meaningful link text, uploaded PDF documents and videos being accessible too, and publishing a statement page describing the site's accessibility status, known gaps and a contact route are all part of that continuity.

Frequently asked questions

Do accessibility toolbars make a site accessible?

No. Add-ons that enlarge text or change colours do not fix missing labels, broken keyboard use or meaningless alternative text in the site's own code. Most people who rely on assistive technology already use their own tools; what they need is for the site itself to be coded correctly.

Can an existing site be made accessible afterwards?

Yes, but the scope depends on how the site is built. Contrast, alternative text and form labels are usually fairly easy to fix. If menus, dialogs and custom components were built without keyboard and screen reader support, those components may need to be rebuilt.

Do PDF documents published on the site need to be accessible too?

Yes. A PDF made of scanned images is a blank page to a screen reader. Documents should be produced text-based, with marked-up heading structure and a correct reading order. Where possible, presenting important information directly on a web page rather than in a PDF is the more accessible solution.

Does accessibility limit design?

It does not limit design; it clarifies certain decisions. Sufficient contrast, readable type sizes and a clear focus indicator are qualities good design should have anyway. When accessibility criteria are built into the design system from the start, they can be applied without compromising the visual identity.

Where should you start with accessibility?

The most productive start is a short audit of contrast, keyboard use, alternative text and form labels on the site's most-used pages and forms; these four areas cover most of the barriers encountered. The fixes should then be carried into the design system and into content editors' habits. At Bir Web Ajans we handle contrast, keyboard use and form labels at design stage, at component level, in the sites we develop.