Accessibility audit services: WCAG audit and fixes in code

In Centrum Komunikacji, a communication app for deaf and blind users, VoiceOver could move past a dialog with 4 controls to 25 controls behind it. We fixed it in the React Native component code. That is how Order Group handles accessibility: the designers, frontend developers and QA who audit your product also change the components afterwards, in React, React Native or Django.

We test websites and native mobile apps. On iOS and Android the screen reader talks to native views, so a fix often goes into a React Native component rather than into HTML.

A report with a list of failures still leaves someone to fix them. What an audit is and what its report contains is explained in our glossary entry on the accessibility audit.

In October 2026 we audited our own website against WCAG 2.2 AA and deployed the fixes. It is still partially compliant, partly because 7 of our 10 YouTube videos have only automatic captions.

A WCAG audit is usually ordered by companies covered by the European Accessibility Act, public bodies, contractors bidding in public tenders and product teams that must show their web or mobile app meets WCAG. These are the rules behind those requirements:

• The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025 to selected digital products and services, including banking, e-commerce and e-books.
• In Poland the Act of 26 April 2024 on ensuring compliance with accessibility requirements of certain products and services by economic operators (Journal of Laws 2024, item 731) implements the directive.
• For Polish public bodies, the Act of 4 April 2019 on the digital accessibility of websites and mobile applications of public bodies (consolidated text, Journal of Laws 2023, item 1440) requires accessible websites and apps and a published accessibility statement.
• Article 100 of the Polish Public Procurement Law requires the description of the contract to include accessibility requirements for people with disabilities when people will use the system. That is how WCAG ends up in tender specifications and contracts.

Whether the EAA covers your service is a question for a lawyer. We check the product against WCAG and fix what fails.

Accessibility remediation means changing components, labels, messages and styles until each failed criterion passes. These are fixes we have made in client projects:

• In the Centrum Komunikacji app, VoiceOver could move past a dialog with 4 controls of its own to 25 controls behind it. The cause was the accessibilityViewIsModal property in React Native, which did not reach the native view. We switched the presentation style to fullScreen and removed the dead property from 3 components (August 2026). This is a focus management problem that a web scanner would not see.
• For PSONI we keep a sheet of all ARIA labels in the web and mobile apps. The same sheet works as the catalogue of error and status messages.
• The PSONI app offers 3 font sizes: 100%, 150% and 200%, which covers the 200% resize in criterion 1.4.4. Users also choose a male or female voice and the reading speed for text-to-speech.
• We fixed the contrast of elements such as the underline that marks the word being read aloud in the text-to-speech module, then retested on staging.
• When text went over the character limit, the button used to turn grey with no explanation. We added a validation message, and the retest passed in September 2026.

Accessibility also starts before the code. The PSONI specification requires a visible text label next to every icon, following WCAG 1.1.1 and W3C guidance for people with cognitive disabilities. A requirement like this has to be met in the interface design, before any code is written, which is where our UX design work comes in.

We test accessibility inside client projects built for people who rely on it every day.

Centrum Komunikacji: WCAG 2.1 AA, screen readers and braille displays

Centrum Komunikacji is a mobile and web app for deaf, hard of hearing, blind and deafblind people. The requirement was WCAG 2.1 AA and compatibility with screen readers and braille displays. We have tested with screen readers throughout the project since November 2025, and our team prepared the WCAG report for the stage 2 sign-off on 27 April 2026.

In September 2026 a blind accessibility expert working with the client tested the production app on iOS and Android. The service tiles read out only the shared button text, so a user could not tell them apart. We changed the labels and retested on both platforms.

PSONI: Generator ETR to WCAG 2.2 AAA

For PSONI (the Polish Association for Persons with Intellectual Disability) we build Generator ETR, a web and mobile app that turns documents into easy-to-read text. The specification requires WCAG 2.2 at level AAA.

The web screen reader round closed on 6 October 2026, and its findings went into a separate fix ticket. The mobile round with TalkBack and VoiceOver was under way in October 2026. The screen reader tests found error messages the screen reader did not announce, a resend-code countdown read out every 5 seconds, and focus jumping to "close" instead of the document content.

Who leads the work

Daria Gusieva has been Head of Design at Order Group since March 2026. She leads UX, UI and WCAG accessibility on client projects and reviews our glossary entries on WCAG 2.2, accessibility audits, screen reader testing and focus management.

On 10 October 2026 we audited ordergroup.co against WCAG 2.2 AA: 48 EN and PL addresses, 55 criteria, axe-core plus manual tests.

Before the fixes, the axe scanner found 6 violations. Manual and scripted tests found more that axe does not check: pixel measurement of text contrast on photos found 29 elements below the threshold on 10 pages, the text spacing test found 5 clipped texts, and the keyboard test found 2 components with an invisible focus.

We fixed the issues in code and deployed the fixes to production. The axe scanner now reports 0 violations, and 0 of the 2140 measured text elements on photos fall below the contrast threshold.

Our result is still "partially compliant". 7 of our 10 YouTube videos have only automatic captions (criterion 1.2.2), and the screen reader test and the review of audio description are still ahead of us. Captions are content, not code: on our site we have to add them ourselves, and on a client's site the content owner does.