Is WCAG compliance mandatory?

It depends on your country, sector and markets. In the EU, for example, the European Accessibility Act covers many digital services. Get legal advice for your exact obligations.

Are automated accessibility tools enough?

No. They quickly catch contrast and missing-label issues, but focus order, meaningful alt text and whether a flow makes sense with a screen reader need manual testing.

Can an existing website be made accessible?

Yes. Start with an audit, then fix the highest-impact issues first. Fixes in shared components and the design system improve many pages at once.

WCAG Accessibility Guide for Web and Mobile Apps

Accessibility means people with visual, hearing, motor or cognitive differences can use your digital product comfortably. This WCAG accessibility guide brings together the core rules for websites and mobile apps, what they mean for design and code, and how to test them.

What is WCAG?

The Web Content Accessibility Guidelines are developed under the W3C and serve as the international reference for web accessibility. The current version, WCAG 2.2, was published in 2023. Although written for the web, its principles apply largely to mobile apps as well.

Level	Meaning	In practice
A	Baseline requirements	If missed, some users cannot access content at all
AA	Standard target	The level most regulations and policies reference
AAA	Highest level	Not always achievable for all content; targeted selectively

For most projects the realistic goal is WCAG 2.2 AA. In the EU, the European Accessibility Act began applying to many digital products and services in June 2025, so for companies serving that market accessibility can be a legal matter too. Seek legal advice for your specific situation.

The four principles: POUR

Perceivable: information must be presentable in ways users can perceive, such as alt text and captions.
Operable: the interface works with mouse, keyboard, touch and assistive tech.
Understandable: content and behavior are predictable; errors are clear.
Robust: content is interpreted correctly by different technologies, including screen readers.

Accessibility in design

Many issues start in the design file, where they are cheapest to fix. In our UI/UX design work we check:

Contrast: at least 4.5:1 for normal text, 3:1 for large text, and 3:1 for meaningful UI elements like input borders and icons.
Not relying on color alone: pair error colors with icons or text.
Target size: WCAG 2.2 AA asks for at least 24x24 CSS pixels, with exceptions. Platform guidance is more generous: Apple recommends 44x44 pt, Material Design 48x48 dp.
Scalable text: layouts should survive larger system font sizes.
Focus states: design a clear keyboard focus style for every interactive component, not just default and pressed states.

When focus styles are missing from the design, developers either leave the browser default or remove it because it looks out of place. Adding a deliberate focus style to the design system solves this at the root. The same applies to error, warning and success messages: decide their wording and placement during design, not during a late bug fix.

Accessibility in web development

Semantic HTML: button for buttons, a for links, a logical heading hierarchy.
Keyboard access: every interactive element reachable with Tab in a sensible order.
Visible focus: never remove focus outlines without a clear replacement.
Alt text: descriptive for meaningful images, empty for decorative ones.
Form labels and errors: visible labels tied to inputs, errors announced to screen readers.
ARIA with restraint: use it only where native HTML falls short; wrong ARIA can be worse than none.

In our Next.js web development projects we solve these at the component level so every page inherits correct behavior.

Accessibility in mobile apps

Screen readers: VoiceOver on iOS, TalkBack on Android. Every interactive element needs a meaningful label, especially icon-only buttons.
Dynamic type: test that text does not truncate and layouts remain scrollable at large sizes.
Reduce motion: simplify big animations when the user has requested it.
Gesture alternatives: swipe-to-delete should also have a button or menu option.

SwiftUI and Jetpack Compose make it straightforward to declare accessibility properties per component, and we build these checks into our mobile app development process.

How to test accessibility

Automated scans with tools like Lighthouse or axe for contrast, missing labels and alt text.
Keyboard-only navigation through the whole page.
Screen reader runs of key flows with VoiceOver, TalkBack or NVDA.
Text size and zoom: enlarge system fonts and zoom web pages to 200 percent.
Real users of assistive technology whenever possible.

Automated tools catch only part of the problems, so manual checks are essential. Treat accessibility as ongoing quality control rather than a one-off audit: add automated checks to your CI pipeline so contrast or labeling regressions are caught before release, and make a quick keyboard and screen reader pass part of your definition of done for every new feature.

WCAG compliance costs least when it is part of design and development from the start, and it makes products better for everyone. BernSoftware builds accessibility into web and mobile projects from the design system to the code. Contact us for an accessibility review or a new project.