The New European Accessibility Standard Raises the Website Bar

A major accessibility standard changed in September 2026. EN 301 549 now adopts WCAG 2.2 for websites, software and digital documents, giving businesses a clearer checklist for accessible design. The update matters most to companies that serve customers in the United Kingdom or other European markets, but its practices benefit every website visitor.

This is not a reason to rebuild a website overnight. It is a reason to review common barriers, document the findings, and include accessibility in normal design, development and content work.

What changed in the standard

EN 301 549 is a European technical standard that supports accessibility requirements for digital products and services. Its September 2026 revision replaces WCAG 2.1 with WCAG 2.2 as the benchmark for websites, software and digital documents.

The revision also adds accessibility requirements that many business websites can address through design and development changes. Reported additions include focus visibility, alternatives to dragging, minimum target size, consistent help, form data reuse and accessible authentication.

The change does not mean every company faces the same legal duties. Applicable rules depend on the organization, its services, its customers and the countries where it operates. A technical standard can guide a review, but it does not replace legal advice.

Why small and midsized businesses should care

Accessibility problems often affect ordinary business tasks. A visitor may struggle to open a menu with a keyboard, identify the current form field, tap a small button, or complete a sign-in process without assistance.

Those barriers can reduce inquiries, purchases and completed applications. They can also increase support requests when visitors cannot understand a form, recover from an error, or find consistent help.

Accessibility work also improves basic website quality. Clear labels, visible focus, readable text, useful error messages and well-sized controls help people using phones, keyboards, screen readers and temporary assistive tools.

Six areas to review first

1. Keyboard focus

Every interactive element should show where keyboard focus sits. This includes links, buttons, menus, dialogs, form fields and controls that appear after a visitor takes an action.

Do not remove the browser focus outline without providing a clear replacement. A visible focus indicator should have enough contrast against nearby colors and should remain noticeable across the entire interaction.

2. Dragging alternatives

Some interfaces ask visitors to drag items, move sliders or reorder content. A visitor who cannot drag with a mouse or touch screen needs another method to complete the same task.

Provide buttons, keyboard controls, direct input fields or another simple option. The alternative should complete the task rather than merely explain that dragging exists.

3. Target size

Small buttons and closely packed links create problems for visitors using touch screens, magnification or limited motor control. Review navigation controls, close buttons, form controls, calendar fields and icon-only actions.

Give controls enough space to select accurately. Spacing matters as well as the visible shape of the control, because neighboring actions can cause accidental selections.

4. Consistent help

Support links, contact options, instructions and help controls should appear consistently across pages that provide similar tasks. Moving help from one location to another makes routine work harder.

Choose a predictable location and label it clearly. If a page includes help, keep its position and wording consistent with related pages whenever possible.

5. Reusing form information

Visitors often enter the same information more than once during an application, checkout or account process. Where the same data is needed again, design the form so visitors can reuse or select existing information.

Use accurate labels and suitable input purposes. Do not ask for information again when the website already has the necessary value and can safely reuse it.

6. Accessible authentication

Sign-in systems can block visitors through visual puzzles, memory tests or complicated steps. Review whether people can authenticate without relying on a single sensory ability or recalling information that the site could safely assist with.

Offer practical alternatives, explain errors in plain language and preserve entered information when a visitor needs to correct a problem. Authentication should protect accounts without creating unnecessary access barriers.

A practical review process

1. List important tasks. Record the actions that matter most, such as requesting an estimate, booking an appointment, submitting an application, creating an account or contacting support.
2. Test with a keyboard. Use only the keyboard to move through each task. Check focus order, visible focus, menus, dialogs, form fields and error recovery.
3. Test on a phone. Check target spacing, orientation, zoom, scrolling and the ability to complete every important action without precision tapping.
4. Inspect forms. Confirm that every field has a clear label, instructions remain available, errors identify the problem, and entered information does not disappear unnecessarily.
5. Review authentication. Test sign-in, password recovery, multifactor steps and account creation. Record any step that depends on memory, vision, hearing or a specific device action.
6. Document fixes. Keep a list of the problem, affected page, user impact, proposed fix, owner and completion date. Re-test after changes.

Do not confuse accessibility with a checklist alone

Automated tools can identify missing labels, low color contrast, duplicate identifiers and some keyboard problems. They cannot reliably judge whether instructions are understandable, focus moves logically, or an authentication process works for real users.

Use automated checks as one part of testing. Combine them with keyboard testing, phone testing, screen reader testing where appropriate, and task-based review by people who can identify practical barriers.

What about WCAG 3?

W3C published a September 2026 WCAG 3 Working Draft, but the project remains under development. A working draft can change before it becomes a finished standard, so it should not replace the current production target.

For present website work, WCAG 2.2 provides the more stable reference. Businesses can monitor WCAG 3 without rewriting current plans around requirements that may change during the standards process.

How to plan the next website update

Add accessibility checks to design reviews, content reviews, development tickets and release testing. Fix barriers on high-value tasks first, then expand the review to older pages, downloadable documents and less frequently used account features.

Keep records of testing and corrections. Clear documentation helps teams maintain progress when staff, content or website features change.

The September update gives businesses a timely reason to review keyboard access, control size, form behavior, help placement and authentication. A website that works for more people is easier to use, easier to maintain and better prepared for changing accessibility expectations.

Sources

• The European accessibility standard EN 301 549 has been updated
• web-standards.dev
• clym.io
• newswire.co.nz
• frontenddogma.com
• releasebot.io

Want a second pair of eyes on this for your own site? Contact us or schedule a call.