The Federal Trade Commission

In January 2025 the FTC filed a complaint against accessiBe, one of the largest overlay vendors, alleging that its claims that its product could make any website compliant with WCAG were false, misleading or unsubstantiated, and that third-party articles and reviews had been formatted to look independent when they were not. In April 2025 the Commission approved the final consent order by a unanimous vote. It requires a payment of 1 million dollars and bars the company from claiming that its automated technology can guarantee or maintain WCAG compliance without competent and reliable scientific evidence. The consent package is on the FTC’s site.

The order is about marketing claims, not about whether overlays are ever useful. But it establishes, from a regulator, that “automatically WCAG compliant” is a claim that needs scientific evidence nobody has produced.

The lawsuit data

UsableNet’s 2026 midyear report notes that lawsuits against companies already using accessibility widgets continue. A toolbar does not make a site usable for a screen reader user who cannot complete checkout, and it does not stop a plaintiff’s firm filing. See our summary of the midyear numbers.

The Caen court

On 4 June 2026 the Caen court ordered Carrefour France to make its website and mobile app fully accessible within six months, with a daily penalty for delay. The site had been assessed as 71 per cent accessible. The judge’s view was that an e-commerce site cannot be a little accessible. It has to be fully accessible. No overlay was at issue in the case, but the reasoning matters here: the EAA sets functional requirements that a service meets or does not. A tool that improves a score without achieving conformance does not change the legal position. Details are in our post on EAA enforcement.

Why the technology cannot get there

Overlays run after the browser has parsed the page. From that position they can change presentation and guess at some fixes, but they face limits that are structural rather than a matter of engineering effort:

• Intent. An alt text describes why an image is there. A script can describe what is in it, which is a different thing, and for icons, charts and product photos often the wrong thing.
• Semantics. A div with a click handler has no role, no name and no keyboard behaviour. Inferring which divs are buttons, what they are called and what state they are in is guesswork at scale.
• Order and focus. Reading order, focus order and focus visibility are properties of the source and the stylesheet. Patching them from outside tends to break as the page updates.
• Timing. Content added after the script runs is missed unless the script keeps re-scanning, which has its own costs.
• Everything that is not a web page. PDFs, native apps and documents are out of reach, and EN 301 549 has clauses for all of them.
• Users’ own tools. People who rely on assistive technology already have magnification, contrast and reading settings. A second layer of controls can conflict with them.

What the EAA actually asks for

The EAA requires in-scope services to meet the functional requirements in Annex I and requires providers to publish information explaining how the service meets them (Annex V). The harmonised standard, EN 301 549 V4.1.1, maps its clauses to those requirements in a new Annex ZB. Conformity is demonstrated clause by clause against the product itself, and an overlay produces no evidence at that level. Where automation genuinely helps is detection: automated engines such as axe-core find the common failures quickly and repeatably, monitoring catches regressions, and AI-drafted alt text reviewed by a person speeds up remediation. The fixes still go in the code.

Try it this week

If your site runs an overlay, audit a key page with Accessibility Checker with the overlay enabled and again with it disabled, and compare the findings. Then read An EAA compliance workflow and Testing and conformance, which describe what evidence a regulator can use.

VoiceOver Image Explorer

VoiceOver can now produce far more detailed descriptions of images across the system, including photos, scanned bills and documents, using Apple Intelligence on supported devices. On iPhone, pressing the Action button lets a VoiceOver user ask questions about what the camera sees and follow up in natural language.

What it needs from you: nothing replaces an accessibility label written by someone who knows what the image is for. Generated descriptions describe what is visible, not why it is there. A chart, an icon that carries meaning or a product photo still needs a label from the app. Treat Image Explorer as the user’s safety net, not your alt text strategy.

Voice Control understands descriptions

Voice Control now accepts natural-language commands that refer to what is on screen, such as “tap the purple folder”, instead of requiring the user to read out a label or a number overlay. It launched in English for the US, UK, Canada and Australia. Apple notes that it can help when elements lack accessibility labels.

What it needs from you: a stable accessibility tree. Natural-language targeting still resolves to elements, and elements with a sensible accessibility label, a visible text equivalent and a correct trait are far easier to hit than anonymous image buttons. Do not read “helps with unlabelled elements” as permission to leave elements unlabelled.

Generated Subtitles

Any video playing without captions can get on-device, automatically generated subtitles on iPhone, iPad, Mac, Apple TV and Vision Pro. It launched in English for the US and Canada.

What it needs from you: if you publish video, keep publishing real captions. Generated subtitles are a fallback for content that has none. They are not a substitute for the captions and audio description WCAG guideline 1.2 asks for, and they do not exist in most languages yet.

Accessibility Reader

Accessibility Reader, introduced last year, now handles complex layouts such as multi-column articles, images and tables, offers on-demand summaries, and translates while keeping the reader’s chosen font, colour and formatting.

What it needs from you: real text. Text baked into images, custom-drawn text and PDFs without a text layer cannot be reflowed, summarised or translated. Support Dynamic Type and let text be text.

Also shipping

• Magnifier adds generated visual descriptions to its high-contrast interface, with spoken commands such as “zoom in”.
• Name Recognition, which alerts deaf and hard-of-hearing users when their name is spoken, expands to more than 50 languages.
• Larger Text arrives on tvOS, so Apple TV apps need to respect text size settings too.
• The Sony Access controller works as a game controller on iOS, iPadOS and macOS.
• On Vision Pro, eye tracking can drive compatible power wheelchairs from Tolt and LUCI in the US, and new face gestures and dwell selection arrive.
• A FaceTime API lets sign language interpretation apps add a human interpreter to a call.

MacRumors has a complete summary of the May preview, and AppleVis covers what shipped for blind and deafblind users.

Accessibility Nutrition Labels

The App Store’s Accessibility Nutrition Labels, introduced with iOS 26 in 2025, let you declare support for VoiceOver, Voice Control, Larger Text, Sufficient Contrast, Reduced Motion, captions and more on your product page. They remain voluntary. Apple said at launch that they would become required at a later date, and as of writing no date has been announced. Filling them in now is cheap, and claiming support you cannot back up is not, so test before you tick.

Meanwhile on Android

Google’s TalkBack 17.0 moves screen and image descriptions to the Gemini 2.5 Flash Lite model, lets braille display users customise commands, improves physical keyboard support and makes announcements on dynamic web pages follow a more logical order, with critical alerts interrupting and lesser updates waiting. The release notes are short and worth a read. The lesson is the same on both platforms: the AI describes, your semantics decide.

Try it this week

Take a screenshot of a busy screen in your own app and run it through the Color Contrast tool in Accessibility Checker, then open the same screen in Xcode’s Accessibility Inspector and fix every control without a label. Finish by trying the screen with Voice Control’s natural-language commands. Clause 11 of EN 301 549 is where mobile apps are assessed in Europe. The lesson Clause 11: software and apps explains how.

Where WCAG 3 stands

WCAG 3 is a successor to WCAG 2.2, not a replacement for it. The W3C says plainly that WCAG 3 “does not deprecate WCAG 2” and that WCAG 2 “will still be required by different countries for a long time to come”. The draft is “not expected to be a completed W3C standard for a few more years”, and even after it is finished WCAG 2 will not be deprecated for several years.

Every section of the draft carries a status: placeholder, exploratory, developing, refining or mature. The September draft includes all requirements that have reached the developing status, which is the midpoint of that scale. That tells you how far there is to go.

The structure

WCAG 2 has principles, guidelines and success criteria. WCAG 3 has guidelines written as outcome statements, and under each guideline sit requirements. The draft distinguishes core requirements, supplemental requirements, assertions and recommended practices. Methods play the role that techniques play in WCAG 2, and “How to” documents correspond to the Understanding documents.

Requirements are far more granular than WCAG 2 success criteria. Many are written in an “applies when” and “except when” form that states the condition that triggers the requirement and the situations it does not cover. The W3C is explicitly asking whether that format is understandable and whether the finer granularity helps or whether requirements should be consolidated.

One conformance level, six reporting tiers

Earlier WCAG 3 drafts experimented with Bronze, Silver and Gold levels and with percentage scoring. The current proposal is simpler at its core: there is one conformance level. “To conform to WCAG 3, content must meet all core requirements.”

Each core requirement carries one of four tags describing the impact when it is not met:

• Physical harm: the content can cause immediate physical harm to a person with a disability.
• Risk: it unreasonably increases financial, medical, legal, privacy or security risk.
• Barrier: it can prevent a person with a disability from proceeding.
• Friction: it can hinder a person with a disability.

The tags feed six reporting tiers. Tier 1 covers physical harm and risk requirements. Tier 2 adds barrier requirements. Tier 3 adds friction requirements, which means all core requirements, and is the conformance point. Tiers 4 and 5 add supplemental requirements and assertions about the content, more of them at Tier 5. Tier 6 adds assertions about the organisation, such as the procedures it follows.

The idea is that a team that cannot yet claim conformance can still report honestly where it stands, and a team that goes further can show that too. The Explainer also describes an alternative approach in which the same tags generate a score above and below conformance, and the W3C wants to hear the pros and cons of each approach before choosing.

What the W3C is asking

The feedback requests in this draft are unusually specific. Does the single level with tags improve on earlier drafts? Are there user needs the requirements do not cover? Is the “applies when” format clear? Do the conformance and reporting changes make adoption easier? The group is also asking for research on gaps, especially for non-Latin scripts and languages.

Comments go to the w3c/wcag3 repository on GitHub, one issue per topic, or by email to public-agwg-comments@w3.org with “[wcag-3.0]” in the subject.

What this means for your roadmap

Nothing in law points at WCAG 3, and nothing will for years. The EAA’s harmonised standard, EN 301 549 V4.1.1, moved to WCAG 2.2 only last month (see our post on the new edition). The US rules cite WCAG 2.1. If you meet WCAG 2.2 Level AA now, the W3C expects you to meet most of WCAG 3’s minimum level when it arrives, with additional work for full conformance.

Where WCAG 3 is worth following is in the thinking. The impact tags are a useful way to triage an audit backlog today: fix the physical harm and risk items first, then barriers, then friction. The APCA contrast method, which has been researched for WCAG 3, is already available alongside the WCAG 2 ratios in Accessibility Checker, so you can compare the two on your own palette.

The draft itself is at w3.org/TR/wcag-3.0, and the WCAG 3 Introduction is the best short summary of the conformance model.

Try it this week

Take the open issues from your last audit and tag each one as physical harm, risk, barrier or friction, then reorder the backlog. Then read What is new in WCAG 2.2, since 2.2 is the version every current law is converging on.

The short answer

Build and test to WCAG 2.2 Level AA. It contains everything in 2.1 Level AA except the removed 4.1.1 Parsing criterion, so meeting 2.2 satisfies every regime below. Report against whichever version the law or contract names, and say which edition your audit used.

European Union

• European Accessibility Act (Directive 2019/882). The directive sets functional requirements and does not name WCAG. Conformity is shown through the harmonised standard EN 301 549. The edition cited in the Official Journal is V3.2.1, which references WCAG 2.1 Level A and AA. V4.1.1, published on 2 September 2026, moves to WCAG 2.2 and maps itself to the EAA in Annex ZB, but it has not yet been cited, so it does not yet give a presumption of conformity. See our post on the new edition.
• Web Accessibility Directive (2016/2102, public sector). The Commission’s implementing decision cites EN 301 549 V3.2.1, so WCAG 2.1 Level AA in practice, until the decision is updated.
• National laws. Transpositions vary. France’s RGAA and Germany’s BITV sit on top of EN 301 549, and courts have started to rule on scope and on what “accessible” means (see our enforcement round-up).

United Kingdom

• Public sector. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 apply. The GOV.UK guidance says public sector bodies should meet WCAG 2.2 Level AA and publish an accessibility statement. The Government Digital Service monitors a sample of sites and apps each year. The Equality and Human Rights Commission and the Equality Commission for Northern Ireland enforce.
• Private sector. The Equality Act 2010 requires reasonable adjustments and names no technical standard. WCAG 2.2 Level AA is the benchmark a court or regulator would expect you to have considered. The UK is outside the EAA, but UK businesses selling into the EU are inside it.

United States

• ADA Title II (state and local government). WCAG 2.1 Level A and AA, by rule. Compliance dates were moved to 26 April 2027 and 26 April 2028 (see our post on the extensions).
• Section 504, HHS (health and human services). WCAG 2.1 Level A and AA, by rule, from 11 May 2027 and 10 May 2028. The rule allows a different standard such as WCAG 2.2 where it provides substantially equivalent or greater accessibility.
• Section 508 (federal agencies and their suppliers). The 2017 refresh of the Section 508 standards incorporates WCAG 2.0 Level A and AA. Conformance report templates (VPATs) now cover 2.0, 2.1 and 2.2, and buyers increasingly ask for 2.1 or 2.2.
• ADA Title III (private businesses). No standard is written into regulation. Court orders and settlements have consistently referenced WCAG 2.1 Level AA.

Standards that are not law

• WCAG 3.0 is a Working Draft, most recently updated on 10 September 2026, and will not be a standard for several years. It is not a target for any law (see our explainer).
• WAI-ARIA 1.3 is also still a Working Draft. ARIA 1.2 remains the Recommendation. The companion ARIA in HTML specification, which says which roles and attributes are allowed on which HTML elements, was republished as a Recommendation on 11 August 2026.

What this means for your evidence

1. One target, several reports. Test once against WCAG 2.2 Level AA and EN 301 549 V4.1.1, then produce a report per regime that names the version it is answering.
2. Name the edition. “Conforms to EN 301 549” means nothing without a version. Ask suppliers the same.
3. Watch two dates. Citation of V4.1.1 in the Official Journal, and any update to the Web Accessibility Directive’s implementing decision. Both change the version Europe officially points at.
4. Keep the parsing check out. 4.1.1 is gone in 2.2 and void in V4.1.1. Reports that still list it look out of date.

Try it this week

Pull up your latest audit report and check which WCAG version and which EN 301 549 edition it names. If it says 2.1 and V3.2.1, test the six WCAG 2.2 criteria that are new. Then take the lesson How WCAG, EN 301 549 and the EAA fit together, which walks through this map in more depth.

Here is what changed, what has not changed yet, and what to do about it.

WCAG 2.2 replaces WCAG 2.1

V3.2.1 built its web, document and software clauses on WCAG 2.1 Level A and AA. V4.1.1 moves the baseline to WCAG 2.2. Clause 9 (web content) now carries every WCAG 2.2 Level A and AA success criterion, and clauses 10 (non-web documents) and 11 (non-web software, which includes mobile apps) are updated to match, with the usual adaptations for content that is not a web page.

Compared with the WCAG 2.1 baseline, six success criteria are new:

• 2.4.11 Focus Not Obscured (Minimum)
• 2.5.7 Dragging Movements
• 2.5.8 Target Size (Minimum)
• 3.2.6 Consistent Help
• 3.3.7 Redundant Entry
• 3.3.8 Accessible Authentication (Minimum)

One criterion has gone. WCAG 2.2 removed 4.1.1 Parsing, so clause 9.4.1.1 in the new edition is marked void. If your test plan still has a parsing check, you can retire it.

New annexes map the standard to the EAA

The most important structural change is Annex ZB, which maps the standard’s requirements to the accessibility requirements in Annex I of the EAA. Annex ZA does the same job for the Web Accessibility Directive, which covers public sector websites and apps. A new clause A.2 supports assessing a specific product or service category against the EAA requirements that apply to it.

Until now, anyone trying to show that a service met the EAA had to build that mapping themselves. The new annexes give everybody the same starting point.

Elsewhere, the real-time text requirements in clause 6.2 are substantially revised, including concurrent voice and text, clause 6.7 extends towards “total conversation” combining text, voice and video, and the user preference requirements are reworked so they read consistently across web, documents and software.

What has not changed yet

Publication by the standards bodies is not the same as citation in the Official Journal of the European Union. Until the Commission cites V4.1.1 in the Official Journal, conforming to it does not give a presumption of conformity with the EAA. For the Web Accessibility Directive, the Commission’s implementing decision still cites V3.2.1, and that does not change until the decision is updated.

ETSI’s own planning documents gave a provisional target of 30 November 2026 for citation. Treat that as a planning date rather than a deadline. The EAA itself has applied since 28 June 2025 regardless. The standard is the easiest route to showing conformity, not the obligation itself.

What to do now

1. Record what applies to you today. Note the laws, contracts and standard editions you are currently held to, then treat V4.1.1 as the readiness target.
2. Close the WCAG 2.2 gap. If your last audit was against WCAG 2.1, test the six new criteria. Target size and accessible authentication catch out a lot of otherwise careful teams, and dragging movements matters for any touch interface.
3. Do not relabel. A WCAG 2.1 audit report is not evidence against V4.1.1, and WCAG 2.2 AA conformance is not the same as full EN 301 549 conformance. The standard has clauses for hardware, documents, authoring tools, support services and more.
4. Ask suppliers which edition their evidence covers. Accessibility conformance reports should name the edition and the clauses tested.
5. Update your statement. If your accessibility statement names EN 301 549 V3.2.1, plan the wording change for when citation happens.

The published text is on ETSI’s delivery server. Davis Wright Tremaine has a useful legal summary, and Pivotal Accessibility published a clause-level walkthrough.

Try it this week

Run an Audit in Accessibility Checker on one key page and look for target-size findings among the results, since 2.5.8 is one of the new WCAG 2.2 criteria. Then read the lesson How EN 301 549 works for the structure of the standard, and Clause 9: web for how the WCAG criteria are incorporated.

How agents read a page

Agents have three ways to perceive a page: the DOM, screenshots, or the accessibility tree the browser derives from the DOM. The tree is cheaper in tokens than an image and states outright what each element is and what it is called, so it is the preferred input where it works. Microsoft’s Playwright MCP server, widely used to give models a browser, states that it uses the accessibility tree rather than pixel-based input. OpenAI’s publisher FAQ for its Atlas browser says the browser uses ARIA tags, the same labels and roles that support screen readers. Its earlier Operator agent worked mainly from screenshots, and hybrid approaches combine the tree with vision for canvas-rendered interfaces the tree cannot describe.

Google has gone further and built it into tooling. Earlier this year Lighthouse gained an Agentic Browsing category. Its scoring documentation says agents rely on the accessibility tree as their primary data model and describes the tree as a core metric for agentic navigation. The audits it runs are a subset of the accessibility audits: interactive elements have programmatic names, roles and parent-child relationships are valid, and interactive content is exposed to the tree. It also measures layout shift, because an element that moves between being identified and being clicked defeats an agent, and checks for an llms.txt file. The category is informational for now and not yet benchmarked.

The scale is not small. Cloudflare Radar measured 57.2 per cent of HTML requests in the week to 5 June 2026 as coming from bots, as Search Engine Journal reported in a good explainer of the tree.

What breaks the tree

The list is familiar because it is the WebAIM Million list (see our summary):

• Empty links and buttons produce nodes with a role but no name. An agent cannot tell “Add to basket” from “Remove”.
• Unlabelled inputs cannot be mapped to a purpose, so they cannot be filled.
• Clickable divs become nameless, roleless nodes that neither a screen reader nor an agent can trust.
• Missing alt text contributes nothing to the tree.
• Over-used ARIA gives confident but wrong information. WebAIM found pages with ARIA averaged 59.1 errors against 42 without.
• Canvas rendering and client-only content leave the tree empty where the key information is.

The AI-generated code problem

There is an irony here. In a July 2026 post, Deque’s chief executive Preety Kumar collected several data points on the code that AI assistants produce. In Deque’s survey of 200 engineering leaders, 88 per cent said they trust their AI-generated code to be accessible. Yet in Microsoft’s evaluation framework six of ten models failed every automated accessibility test, and in the GAAD Foundation’s AIMAC benchmark 35 of 37 leading models produced multiple critical or serious issues by default. Models generate markup that looks right and exposes nothing, and the agents built by the same industry then struggle to use it.

What to do

1. Native elements first. A button is a button element, a link has an href, a select is a select. This is the W3C’s first rule of ARIA and it is what agents parse best.
2. Name everything. Every link, button and input has a visible label or an accessible name, including icon-only controls.
3. Render the facts in HTML. Prices, availability, specifications and the primary action should be server-rendered text, not images or canvas.
4. Use ARIA for gaps, not decoration. Check that every aria-hidden and role attribute earns its place.
5. Look at the tree. Browser developer tools show the accessibility tree directly. Confirm each important action has a clear role and name. The same applies to native apps: VoiceOver and the natural-language Voice Control Apple has announced for iOS 27 both resolve to the app’s accessibility elements.
6. Review generated code as code. Put an automated accessibility check in the pipeline and treat its failures as build failures, whoever or whatever wrote the markup.

None of this changes the reason to do it. People come first, and the law is written for people. But if you have struggled to get accessibility work prioritised, the fact that the same work decides whether your site works in an agent-mediated purchase is an argument that lands with people who did not listen before.

Try it this week

Audit your most important page in Accessibility Checker. Every empty link, empty button and unlabelled field it reports is a node an agent cannot use either. Then read WCAG: Robust, the principle about exposing name, role and value.

Who is being sued

• E-commerce dominates. 79 per cent of suits in the first half targeted e-commerce sites, with food and beverage services the other heavy category.
• Not just big companies. 68 per cent of suits involved companies with annual revenue under 50 million dollars. At the same time the share of defendants above 25 million dollars in revenue has grown steadily, from 27 per cent in 2023 to 33 per cent in 2024 and 36 per cent this year.
• Widgets do not deter plaintiffs. UsableNet reports that lawsuits against companies already using accessibility widgets continue. If anything the toolbar signals that the owner knows accessibility is an issue.

Where, and by whom

New York still leads in total filings. The story of 2026 is Illinois, which has moved into second place on the back of state-court claims. Florida is the most active federal jurisdiction, and California remains a major venue. A small group of plaintiff firms drives most filings, with one, Equal Access Law Group, described as the single biggest driver of this year’s surge. UsableNet also notes that federal enforcement has slowed, through delays to the ADA Title II web rule and limited Department of Justice involvement, and that private plaintiffs and state courts have filled the gap. The full midyear analysis has the charts.

One state has pushed back. Missouri’s Act Against Abusive Website Access Litigation (SB 907) takes effect on 28 August 2026 and introduces a 90-day cure period with fee-shifting against plaintiffs who sue after a defect has been fixed. Whether other states follow is an open question. So far they have not.

Why a UK or EU company should care

Title III of the ADA covers places of public accommodation, and many US courts have treated the websites and apps of businesses serving American customers as covered. Being based outside the US has not stopped demand letters arriving. A retailer shipping to the US, a SaaS product sold to US customers or an app in the US App Store is in reach. No technical standard is written into Title III regulations, but settlements and court orders have consistently referenced WCAG 2.1 Level AA, the same standard the Title II and Section 504 rules now mandate.

In Europe the enforcement track is different, driven by regulators and disability associations rather than plaintiffs’ firms, but the direction is the same. The Caen court’s June order against Carrefour, covered in our post on EAA enforcement, rejected a 71 per cent conformity score as inadequate. Both systems are converging on the same expectation: full WCAG conformance, documented.

Reducing the risk

1. Fix the common failures first. The complaints in these suits are repetitive: missing alt text, unlabelled form fields, empty links and buttons, keyboard traps and inaccessible checkout flows. WebAIM’s 2026 data shows the same list across the top million sites (see our summary).
2. Test the money path manually. Search, product page, basket, checkout and account, with a keyboard and a screen reader. Most suits are about not being able to buy.
3. Publish an accessibility statement and a contact route, and answer it. Plaintiffs’ firms look for silence.
4. Keep the evidence. Audit reports with dates, the issues fixed and the standard tested against. In the US it supports a defence. In the EU it is what the regulator will ask for.
5. Do not rely on an overlay. A widget does not remove the failures a plaintiff’s tester will find, and the FTC’s 2025 order against accessiBe shows regulators take the same view of “automatically compliant” claims.

Try it this week

Run the Audit in Accessibility Checker on your checkout page and export the report as a dated PDF. Then read Why accessibility, which sets out the business and legal case in one place.

France: the courts move first

The most consequential enforcement so far has come from disability associations rather than regulators. Droit Pluriel and ApiDV, supported by the lawyers’ collective Intérêt à agir, brought proceedings against four French grocery retailers over the accessibility of their online shopping services.

On 5 May 2026 the Lille court dismissed the case against Auchan’s e-commerce subsidiary on scope. The French decree implementing the 2005 disability law applies its web accessibility duty to companies with average turnover above 250 million euros, and the subsidiary’s 2024 turnover was 144 million euros. The associations have appealed to the Douai court of appeal.

On 4 June 2026 the Caen court reached the opposite result against Carrefour France. It ordered the company to make carrefour.fr and its mobile app fully accessible within six months, with a penalty of 500 euros for every day of delay after that. Carrefour’s site had been assessed as 71 per cent accessible. The judge’s reasoning, in translation, was that an e-commerce site “cannot be just a little accessible, it must be totally accessible”. The order relied on article L.412-13 of the French consumer code, which is where France transposed the EAA’s e-commerce obligations and which applies to online retailers above a 2 million euro turnover threshold, alongside the older 2005 law.

Two points stand out. First, the court treated the mobile app as squarely in scope. Second, a partial conformity score was not a defence. Coverage in Faire Face and Handicap.fr has the detail. Both decisions are first-instance and open to appeal.

Regulators: investigations, not yet penalties

• Sweden. In October 2025 the telecoms regulator PTS opened 28 investigations into e-commerce websites on its own initiative, with no complaint needed. No decisions have been published.
• Netherlands. The consumer and markets authority ACM required in-scope businesses to self-report by 15 October 2025 and has been auditing companies that did not. Again, no published decisions.
• Germany. The federal market surveillance body for accessibility in Magdeburg has been operating since 26 September 2025 and has taken no public action. The warning letters that circulated in 2025 came from private law firms.
• Ireland. ComReg is processing complaints, including a publicised one against a mobile operator in December 2025. Irish law provides for criminal penalties but none has been used.
• Italy. AgID published private-sector compliance guidelines on 4 March 2026.

The one monetary penalty in the wider European Economic Area, a daily fine against a Norwegian health portal in December 2025, was issued under Norway’s older domestic law rather than the EAA, and the portal fixed the problem within days. A running tally by Auditsu tracks these cases. It is a vendor source and worth cross-checking, but it cites the court and regulator documents.

What this tells you

1. Scope thresholds are being litigated. Which law applies, and which turnover test, decided the Lille case. Know which national transposition covers you and keep the evidence for your microenterprise or disproportionate burden position if you rely on one. The lesson Exemptions and disproportionate burden covers how.
2. “Mostly accessible” is not the standard. The EAA’s requirements are functional and binary. A 71 per cent score sounds like progress to a product team and reads as non-compliance to a judge.
3. Apps are in. If your service has an app, the app is part of the service.
4. Enforcement is complaint-driven and association-driven. The feedback mechanism the EAA requires is not a formality. A complaint you answer well is one that does not reach a regulator or a court.
5. The standard is about to change. EN 301 549 V4.1.1, which moves the baseline to WCAG 2.2 and maps the standard to the EAA in a new annex, is in its final approval vote at ETSI, CEN and CENELEC and is expected to be published later this year. Audits against WCAG 2.1 will need topping up.

Try it this week

Use Accessibility Checker to generate a draft accessibility statement for one service and compare what you can honestly say against what the EAA’s Annex V asks you to disclose. Then work through EAA obligations and An EAA compliance workflow.

ADA Title II: state and local government

The Department of Justice’s 2024 rule under Title II of the Americans with Disabilities Act requires state and local governments to make their web content and mobile apps conform to WCAG 2.1 Level A and AA, including content and apps provided for them by contractors. On 20 April 2026 the DOJ published an interim final rule in the Federal Register extending both compliance dates by one year:

• Public entities serving a population of 50,000 or more: from 24 April 2026 to 26 April 2027.
• Smaller entities and special district governments: from 26 April 2027 to 26 April 2028.

The DOJ said it had overestimated how quickly covered entities could comply, and that it plans further rulemaking on the rule’s substantive requirements. If no proposed rule follows and the dates are not extended again, the DOJ expects the rule to apply on the new dates. The interim rule changed nothing else: the technical standard, the coverage of apps and documents, and the exceptions for archived content, pre-existing documents, individualised password-protected documents, pre-existing social media posts and third-party content all stand. Reed Smith has a clear summary, and the DOJ’s fact sheet on the rule remains the best plain-language guide to what it covers.

HHS Section 504: health and human services

The Department of Health and Human Services’ May 2024 rule under Section 504 of the Rehabilitation Act applies the same WCAG 2.1 Level A and AA standard to the websites, mobile apps and kiosks of anyone receiving HHS financial assistance. That reaches most hospitals, physician practices, health centres, care facilities, health plans and medical schools. Accepting Medicare Part B reimbursement alone is enough to be covered.

On 7 May 2026 HHS’s Office for Civil Rights issued its own interim final rule, published in the Federal Register on 11 May, moving the digital deadlines back a year:

• Recipients with 15 or more employees: from 11 May 2026 to 11 May 2027.
• Recipients with fewer than 15 employees: from 10 May 2027 to 10 May 2028.

The stated reason was that a significant number of recipients reported they could not meet the original timeline, and the change brings HHS into line with the DOJ. Everything else in the 2024 rule stands, including the general duty not to discriminate, which has been in force since 8 July 2024 and does not wait for the web deadline. The rule also allows an alternative standard such as WCAG 2.2 where it gives substantially equivalent or greater accessibility. The Federal Register notice is the primary source.

What did not slow down

Private litigation. UsableNet’s running lawsuit tracker, which counts filings in federal court and the main state courts, shows 2026 filings ahead of the same period in 2025. With federal enforcement paused, private plaintiffs and state courts set the pace, and they do not wait for compliance dates.

How to use the extra year

1. Do not re-plan to the new date. Teams that were on track for 2026 should finish. The deadline moved, the backlog did not.
2. Inventory documents. Both rules reach PDFs, spreadsheets and presentations that are used to access services, not just HTML. Archived and pre-existing documents are exempt only while they stay unaltered and are not currently used to apply for, access or take part in a service.
3. Fix contracts. Content a vendor provides on your behalf is your obligation. Put the standard, the edition and the evidence you expect into the agreement.
4. Build to 2.2, report against 2.1. WCAG 2.2 Level AA is a superset of 2.1 Level AA apart from the removed parsing criterion, and it is where Europe has moved. Meeting 2.2 covers both.

Try it this week

Pick one public-facing form and check it against the three WCAG 2.2 criteria that most often trip up government services: redundant entry, accessible authentication and target size. Then read How WCAG, EN 301 549 and the EAA fit together for a map of which law points at which version.

The headline figures

• 95.9 per cent of home pages had detectable WCAG 2 failures, up from 94.8 per cent in 2025.
• 56.1 errors per page on average, a total of 56,114,377, up 10.1 per cent from 51 per page the year before.
• Home pages averaged 1,437 elements, up from 1,257 a year earlier. A user who relies on assistive technology meets an error roughly every 26 elements.

Remember what this measures. Automated tools detect only a portion of WCAG failures, so the true rate of non-conformance is higher, not lower.

The six errors

As in every previous year, six error types account for the overwhelming majority of what was found:

1. Low-contrast text: 83.9 per cent of pages.
2. Missing alternative text for images: 53.1 per cent.
3. Missing form input labels: 51 per cent.
4. Empty links: 46.3 per cent.
5. Empty buttons: 30.6 per cent.
6. Missing document language: 13.5 per cent.

Missing alt text and missing language declined slightly. The other four rose. None of these requires a specialist to detect, and each maps to a WCAG success criterion that has been stable since WCAG 2.0 in 2008 (contrast at Level AA, the rest at Level A).

ARIA is still making things worse

82.7 per cent of home pages now use ARIA, up from 79.4 per cent, and the volume keeps climbing: more than 133 ARIA attributes per page, up 27 per cent in a year. Pages with ARIA averaged 59.1 errors against 42 on pages without it. Pages averaged 23.3 instances of aria-hidden="true" and 4.8 of role="button". Of the 5.7 per cent of pages with an ARIA menu, 22 per cent of those menus introduced barriers.

The lesson has not changed since the first report: ARIA used to patch over non-semantic markup correlates with more errors, not fewer. Native HTML elements first, ARIA for what HTML cannot express.

Frameworks, platforms and sectors

The report found that the presence of nearly every popular JavaScript library was associated with more detected errors. Among the frameworks WebAIM lists, Astro pages had the fewest errors at 9.0 per page and Firebase-hosted pages the most at 82.9. Next.js (40.9) and React (43.5) sat below the overall average. Among content management systems, WordPress, which appeared on 252,302 of the pages, averaged 52.8 errors, a little under the mean, while Adobe Experience Manager (29.9), Squarespace (33.0) and Wix (33.3) did noticeably better. Government sites were the best sector at 42.4 errors per page, and sports (71.4) and shopping (71.0) the worst, which is uncomfortable reading for anyone in e-commerce facing the European Accessibility Act.

Skip links are one small bright spot: 17.1 per cent of pages had one, up from 15.3 per cent, though about one in ten of them was broken.

The full report is at webaim.org/projects/million.

Finding the six in your own work

All six errors are detectable by automated checks, which is exactly what the Audit tool in Accessibility Checker runs, using the same axe-core engine most teams use in their pipelines. Contrast is the one that needs a designer’s eye as well as a tool: the Color Contrast tool checks any screenshot, website or live camera view against the WCAG ratios and suggests accessible alternatives.

For native apps the same six have equivalents: unlabelled buttons and images, missing labels on form fields, low-contrast text that does not adapt to Increase Contrast, and controls built from plain views without traits. Xcode’s Accessibility Inspector finds most of them.

Try it this week

Audit your own home page and count how many of the six appear. Then read WCAG: Perceivable, which covers contrast and text alternatives, the two most common failures in the report.

How does EAA relate to WCAG?

EN 301 549 is directly related to the European Accessibility Act (EAA), which is legislation aimed at improving the accessibility of products and services across the European Union.

EN 301 549 makes extensive references to the Web Content Accessibility Guidelines (WCAG) 2.1, integrating its success criteria as benchmarks for accessibility in ICT products and services. Here are the key references:

1. General Integration:
   • The document integrates various success criteria from WCAG 2.1 across different sections to ensure web content accessibility. It states that ICT products and services must meet these criteria to be considered accessible.
2. Specific Success Criteria:
   • Timing Adjustable: Where ICT is a web page, it must satisfy WCAG 2.1 Success Criterion 2.2.1.
   • Pause, Stop, Hide: Where ICT is a web page, it must satisfy WCAG 2.1 Success Criterion 2.2.2.
   • Three Flashes or Below Threshold: Where ICT is a web page, it must satisfy WCAG 2.1 Success Criterion 2.3.1.
   • Keyboard Accessibility: ICT web pages must satisfy WCAG 2.1 Success Criteria 2.1.1 and 2.1.2.
   • Error Identification and Suggestion: Web pages must meet WCAG 2.1 Success Criteria 3.3.1 and 3.3.3.
3. Testing and Evaluation:
   • Annex C of the document provides detailed procedures for assessing conformance to WCAG 2.1 success criteria through inspections and checks.
4. Level AAA Success Criteria:
   • The document encourages considering WCAG 2.1 Level AAA success criteria, even though it is not recommended to require these for entire sites as a general policy due to the difficulty of satisfying all criteria.
5. Non-Web Documents:
   • Non-web documents must also satisfy specific WCAG 2.1 success criteria, such as meaningful sequence, sensory characteristics, and use of color.
6. Conformance Requirements:
   • EN 301 549 includes a section on WCAG 2.1 conformance requirements, detailing the conditions under which ICT must comply with WCAG standards to ensure full accessibility.

Additional References in EN 301 549

EN 301 549 includes several references beyond WCAG, which are both normative and informative. These references support various aspects of accessibility for ICT products and services. Here are the additional references:

Normative References

1. ETSI Standards:
   • ETSI ETS 300 381: "Telephony for hearing impaired people; Inductive coupling of telephone earphones to hearing aids".
   • ETSI ES 200 381-1: "Telephony for hearing impaired people; Inductive coupling of telephone earphones to hearing aids; Part 1: Fixed-line speech terminals".
   • ETSI ES 200 381-2: "Telephony for hearing impaired people; Inductive coupling of telephone earphones to hearing aids; Part 2: Cellular speech terminals".
2. ISO/IEC Standards:
   • ISO/IEC 17007:2009: "Conformity assessment - Guidance for drafting normative documents suitable for use for conformity assessment".

Informative References

1. ANSI/IEEE Standards:
   • ANSI/IEEE C63.19: "American National Standard Method of Measurement of Compatibility between Wireless Communication Devices and Hearing Aids".
   • ANSI/TIA-4965: "Receive volume control requirements for digital and analogue wireline terminals".
2. European Commission:
   • European Commission M 376-EN: "Standardization Mandate to CEN, CENELEC and ETSI in support of European accessibility requirements for public procurement of products and services in the ICT domain".
3. ETSI Human Factors Standards:
   • ETSI EG 201 013: "Human Factors (HF); Definitions, abbreviations and symbols".
   • ETSI ES 202 975: "Human Factors (HF); Requirements for relay services".
   • ETSI ETS 300 767: "Human Factors (HF); Telephone Prepayment Cards; Tactile Identifier".
   • ETSI/CEN/CENELEC TR 101 550: "Documents relevant to EN 301 549 'Accessibility requirements suitable for public procurement of ICT products and services in Europe'".
   • ETSI/CEN/CENELEC TR 101 551: "Guidelines on the use of accessibility award criteria suitable for public procurement of ICT products and services in Europe".
   • ETSI TR 102 612: "Human Factors (HF); European accessibility requirements for public procurement of products and services in the ICT domain (European Commission Mandate M 376, Phase 1)".
4. ITU-T Recommendations:
   • ITU-T E.161: "Arrangement of digits, letters and symbols on telephones and other devices that can be used for gaining access to a telephone network".
   • ITU-T G.722: "7 kHz audio-coding within 64 kbit/s".
   • ITU-T G.722.2: "Wideband coding of speech at around 16 kbit/s using Adaptive Multi-Rate Wideband (AMR-WB)".
   • ITU-T V.18: "Operational and interworking requirements for DCEs operating in the text telephone mode".
5. IETF RFC:
   • IETF RFC 4103: "RTP Payload for Text Conversation".
6. ISO/IEC Standards:
   • ISO 9241-11: "Ergonomics of human-system interaction - Part 11: Usability: Definitions and concepts".
   • ISO 9241-110: "Ergonomics of human-system interaction - Part 110: Dialogue principles".
   • ISO 9241-171: "Ergonomics of human-system interaction - Part 171: Guidance on software accessibility".
   • ISO/IEC 13066-1: "Information technology - Interoperability with assistive technology (AT) - Part 1: Requirements and recommendations for interoperability".
   • ISO/IEC Guide 71: "Guide for addressing accessibility in standards".
   • ISO/IEC TS 20071-25: "Information technology - User interface component accessibility - Part 25: Guidance on the audio presentation of text in videos, including captions, subtitles and other on-screen text".
   • ISO 21542: "Building construction - Accessibility and usability of the built environment".
7. W3C Recommendations:
   • W3C Recommendation: "Authoring Tool Accessibility Guidelines (ATAG) 2.0".
   • W3C Recommendation: "User Agent Accessibility Guidelines (UAAG) 2.0".
8. US Legislation:
   • Section 508 of the United States Rehabilitation Act of 1973, revised 2017.
9. W3C Working Group Note:
   • W3C Working Group Note: "Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)".

These references provide additional frameworks and guidelines that enhance the robustness and comprehensiveness of EN 301 549, ensuring it covers various aspects of accessibility in ICT products and services.

The European Accessibility Act (EAA), formally known as Directive (EU) 2019/882, aims to enhance the accessibility of products and services across the European Union (EU) to create a more inclusive society and ensure equal participation for all individuals, including those with disabilities and functional limitations. Here is an overview based on the document:

Purpose and Scope

The primary objective of the EAA is to harmonize the accessibility requirements for certain products and services within the EU, reducing barriers caused by divergent national regulations and improving the availability and accessibility of these products and services across the internal market.

Key Accessibility Requirements

The EAA sets forth specific accessibility requirements for a variety of products and services. These include:

• Products: Computers, operating systems, ATMs, ticketing and check-in machines, telephones, and smartphones.
• Services: Electronic communications, audio-visual media services, air, bus, rail, and waterborne passenger transport, banking services, e-books, and e-commerce.

Functional Performance Criteria

The Directive includes functional performance criteria to ensure that products and services are accessible to all users, including those with varying types of disabilities. These criteria focus on providing information and functionality that can be used with assistive technologies.

Obligations for Economic Operators

The EAA places specific obligations on manufacturers, importers, and distributors to ensure compliance with accessibility requirements:

• Manufacturers must ensure their products meet the accessibility criteria and conduct conformity assessments.
• Importers and Distributors must verify that products comply with the EAA's requirements before placing them on the market.

Conformity Assessment and CE Marking

Products that comply with the EAA's accessibility requirements must undergo conformity assessments and be marked with the CE marking, indicating compliance with EU standards. This process involves detailed documentation and technical assessments to ensure products meet the necessary criteria.

Exemptions and Derogations

The Directive allows for certain exemptions, particularly for microenterprises and situations where meeting the accessibility requirements would impose a disproportionate burden. These exemptions aim to balance accessibility goals with the practical capabilities of smaller businesses.

Implementation and Enforcement

Member States had to transpose the EAA into national law by June 28, 2022 and apply it from June 28, 2025. Service providers may keep using products they lawfully used before that date to provide similar services, and service contracts agreed before it may run unchanged, until June 28, 2030 at the latest. The Directive includes provisions for market surveillance and enforcement to ensure compliance and handle complaints related to accessibility.

Reporting and Review

The European Commission will periodically review and report on the application of the EAA to assess its impact and effectiveness, considering technological and societal developments. The first report is due by June 28, 2030, with subsequent reports every five years.

The EAA represents a significant step towards a more accessible Europe, aiming to remove barriers and provide equal access to products and services for all individuals, particularly those with disabilities.

* Note this summary was generated by a custom ChatGPT created using the full text PDF of the DIRECTIVE (EU) 2019/882 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17 April 2019 on the accessibility requirements for products and services.

EN 301 549 is a European standard that outlines accessibility requirements for Information and Communication Technology (ICT) products and services. This standard is developed by ETSI in collaboration with CEN and CENELEC, targeting inclusivity and accessibility, particularly in public procurement within Europe.

Key Elements of EN 301 549

1. Scope:
   • The standard applies to a broad range of ICT products and services, including web-based technologies, non-web technologies, software, hardware, and hybrids.
   • It is designed for use by both providers and procurers of ICT products and services.
2. Functional Performance Statements:
   • These statements describe the necessary functionality for ICT to be usable by people with various disabilities, ensuring accessibility without vision, with limited vision, without perception of color, without hearing, with limited hearing, without vocal capability, with limited manipulation or strength, with limited reach, and with limited cognition, language, or learning.
3. Generic and Specific Requirements:
   • Generic Requirements: Address general accessibility needs, such as non-visual access and auditory output.
   • Specific Requirements: Tailored criteria for different types of ICT, including hardware, software, web content, non-web documents, and real-time communication.
4. Testing and Evaluation:
   • Descriptions of test procedures and evaluation methodologies are included for each accessibility requirement, ensuring consistent and reliable results across implementations.
5. Annexes:
   • Annex A: Details the minimum requirements of the European Web Accessibility Directive (Directive 2016/2102).
   • Annex B: Maps the relationships between requirements and functional performance statements.
   • Annex C: Provides a framework for determining conformance.
   • Annex D: Offers resources for cognitive accessibility.
   • Annex E: Guidance for using the standard.
   • Annex F: Change history.

Importance of EN 301 549

• Public Procurement: Provides clear criteria for accessible ICT procurement, ensuring that publicly funded products and services are accessible to all users, including those with disabilities.
• Legal Compliance: Supports compliance with European accessibility directives and regulations, such as Directive 2016/2102 on the accessibility of websites and mobile applications of public sector bodies.
• Inclusive Design: Promotes the development of ICT products and services that are usable by the widest possible range of users, fostering inclusivity and equal access to technology.

Application

• ICT Providers: Use the standard to design and develop accessible products and services.
• Procurers: Evaluate and select accessible ICT products and services based on the criteria set out in the standard.
• Policy Makers: Reference the standard to support legislation and policies aimed at improving accessibility.

EN 301 549 is a comprehensive guide for ensuring the accessibility of ICT products and services, promoting digital inclusion for all users, including those with disabilities.

Relationship Between EN 301 549 and the European Accessibility Act

EN 301 549 is directly related to the European Accessibility Act (EAA), which is legislation aimed at improving the accessibility of products and services across the European Union. Here's how EN 301 549 aligns with and supports the EAA:

1. Harmonized Standard for Public Procurement:
   • EN 301 549 provides a harmonized standard that specifies the accessibility requirements for ICT products and services, making it a crucial reference for public procurement processes in Europe. This is essential for compliance with the EAA, which mandates accessibility in various domains.
2. Directive 2016/2102 Compliance:
   • The document serves as a voluntary means of conforming to the essential requirements of Directive 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies. Annex A of EN 301 549 explicitly details the minimum requirements of this directive, helping organizations ensure their web content and mobile applications are accessible.
3. Conformance and Testing:
   • EN 301 549 outlines test procedures and evaluation methodologies that align with the European Accessibility Act's requirements. This ensures that ICT products and services can be reliably tested for compliance with accessibility standards, facilitating adherence to the EAA.
4. Support for a Wide Range of ICT:
   • The standard covers both web and non-web technologies, software, hardware, and hybrid systems, reflecting the broad scope of the EAA. It includes functional performance statements and specific criteria tailored for different types of ICT, ensuring comprehensive accessibility coverage.
5. Functional Performance and Requirements:
   • EN 301 549 includes functional performance statements and detailed requirements for various types of ICT, which are mapped to the essential requirements of Directive 2016/2102. This mapping ensures that ICT products and services meet the necessary accessibility criteria specified by the EAA.

Summary

EN 301 549 acts as a key technical standard supporting the European Accessibility Act by providing detailed accessibility requirements and testing methodologies for ICT products and services. It aligns with Directive 2016/2102, ensuring that public sector websites and mobile applications are accessible to all users, including those with disabilities. This standard is essential for public procurement and compliance with the EAA, promoting inclusive access to technology across Europe.

The Web Content Accessibility Guidelines (WCAG) is a universally recognized set of recommendations designed to make web content more accessible for individuals with disabilities. Developed by the World Wide Web Consortium (W3C), it has emerged as a vital framework for web accessibility.

But how does WCAG apply to mobile apps, specifically iOS apps? Despite its name, WCAG isn't exclusive to websites and is very applicable to mobile applications. In this post, we'll explore the application of WCAG 2.1 standards to iOS mobile apps.

1. Understanding WCAG 2.1

WCAG 2.1 was the latest version of the guidelines when this guide was written (WCAG 2.2 followed in October 2023), introducing new success criteria addressing mobile accessibility, people with low vision, and people with cognitive and learning disabilities. WCAG 2.1 is organized around four principles: Perceivable, Operable, Understandable, and Robust (POUR).

2. Applying WCAG 2.1 to iOS Apps

Let's explore how these principles can be incorporated into iOS app design and development.

2.1. Perceivable

Perceivable relates to the visibility of the content and information on your app.

• Text Alternatives: Offer text alternatives for non-text content. For example, add descriptive alt text to images and UI elements so that screen readers like VoiceOver on iOS can interpret them.
• Time-Based Media: Provide alternatives for time-based media, like captions for videos or audio descriptions.
• Adaptable: Create content that can be presented in different ways without losing meaning. Make sure your layout works in both portrait and landscape orientations, and elements resize correctly for different screen sizes.
• Distinguishable: Make it easy for users to see and hear content. Ensure there's sufficient contrast between text and background colors. iOS provides Dynamic Type which allows users to specify their preferred text size across all apps that support it.

2.2. Operable

This principle refers to how users interact with your app.

• Keyboard Accessible: All functionality should be operable via a keyboard interface. In the context of iOS, this means ensuring that all features are accessible and usable through different interaction methods, like switch control.
• Enough Time: Provide users enough time to read and use content. If your app contains time-limited processes, ensure you provide options to turn off, adjust, or extend the time limit.
• Seizures and Physical Reactions: Do not include design elements that could cause seizures or physical reactions. Avoid flashing or flickering content.
• Navigable: Provide ways to help users navigate, find content, and determine where they are in the app. Use semantic markup to create a logical structure and clear headings.

2.3. Understandable

This principle relates to how easily users can comprehend the app's content and interface.

• Readable: Make text content readable and understandable. Keep your language simple and clear. iOS supports Text Styles, which conform to the user's selected content size, and also offer automatic adjustments for weight and letter spacing.
• Predictable: Make web pages appear and operate in predictable ways. Maintain consistent navigation and labeling across your app.
• Input Assistance: Help users avoid and correct mistakes. Offer validation and error recovery for forms. Make sure error messages are clear and provide guidance for correction.

2.4. Robust

This principle ensures the app's compatibility with current and future technologies.

• Compatible: Maximize compatibility with current and future user tools. Use valid, clean, and semantic code to ensure your app works well with assistive technologies.

3. WCAG 2.1 Compliance Tools for iOS Apps

Tools like Accessibility Inspector, part of Xcode, can be used to test the accessibility of your app. It provides a range of features to help you assess how successfully your app meets the WCAG 2.1 guidelines.

Conclusion

Making your iOS app accessible is not just a matter of social responsibility or compliance with regulations—it also makes good business sense, broadening your potential user base. As developers and designers, we have a role to play in making digital experiences inclusive and accessible to everyone. Use WCAG 2.1 as your roadmap to create more accessible iOS applications.

In an increasingly digitized world, it is crucial for app developers to make their creations inclusive and accessible to everyone, regardless of their physical, cognitive, or sensory abilities. Accessibility is a fundamental principle, not an add-on feature. Apple has built powerful accessibility features into iOS, and it's essential that you make the most of these to ensure your app is accessible. Here are 10 steps to guide you through the process.

1. Understand Accessibility

Understanding the essence of accessibility is the first step towards creating an inclusive iOS app. Educate yourself about the different types of disabilities and the specific needs of these user groups. Apple's Human Interface Guidelines are a great place to start learning about accessibility principles and how to implement them.

2. Use Built-in Accessibility Features

Make use of iOS's built-in accessibility features, such as VoiceOver, Zoom, Larger Text, and AssistiveTouch. These tools can make your app more accessible to people with visual, motor, or other physical impairments. Ensure that your app supports and works seamlessly with these features.

3. Label All UI Elements

Each user interface (UI) element should have a clear, concise label to help screen readers like VoiceOver convey the purpose of the elements to users with vision impairments. Be descriptive but straightforward with your labels, enabling users to understand the functionality of each element quickly.

4. Color and Contrast

Ensure that your app has a high color contrast ratio. This will make it easier for people with color blindness or vision impairments to distinguish different elements. Always test your app under various color settings and avoid conveying information using color alone.

5. Implement Dynamic Type

Dynamic Type allows users to adjust the font size according to their preference. Incorporating this feature in your app ensures that it can respond to the text size preferences set by the user in the system settings, thereby making your app more accessible to people with vision impairments.

6. Design for Easy Navigation

Ensure your app can be easily navigated using a single finger or an assistive device. Avoid complex gestures, and provide alternate navigation options whenever possible. Also, keep in mind to structure your content logically and provide clear, consistent cues for navigation.

7. Use Captioning and Audio Descriptions

To assist users with hearing impairments, use captions for video content and provide transcripts for audio content. Consider implementing audio descriptions for videos, which will narrate the actions, characters, scene changes, on-screen text, and other visual content.

8. Prioritize User Testing

Testing your app with people who have disabilities is critical. Feedback from real users can help you identify and fix issues that automated tools might miss. Include people with different types of disabilities in your testing process to ensure a broad range of accessibility.

9. Provide Detailed Accessibility Instructions

Include a dedicated section in your app or its documentation detailing the accessibility features you have implemented. This will assist users in understanding how to make the most out of your app's accessibility capabilities.

10. Keep Updating and Improving

Creating an accessible app isn't a one-and-done task. It requires continuous effort to update and improve. Be open to feedback from users and make necessary changes. Technology and user needs are constantly evolving, so ensure your app evolves with them.

Conclusion

Creating an accessible iOS app is an essential and rewarding endeavor. Not only will it ensure a more inclusive experience for all users, but it can also expand your user base and make your app more popular. Use the steps outlined above as a guide, but remember, accessibility is an ongoing process of learning, implementation, testing, and improvement.

When designing digital content, ensuring accessibility is crucial to accommodate individuals with visual impairments. One essential aspect of accessibility is color contrast, which plays a significant role in providing an inclusive experience for all users. In this blog post, we will delve into the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines (WCAG) 2.1 A, AA, and AAA and their relation to color contrast. Let's explore these guidelines and understand how they impact the accessibility of digital content.

1. WCAG 2.1: An Overview
   The WCAG 2.1 is a set of guidelines established by the W3C to make web content more accessible to individuals with disabilities. These guidelines provide specific success criteria that websites and web applications should meet to ensure inclusivity for all users. WCAG 2.1 builds upon its predecessor, WCAG 2.0, by incorporating additional success criteria to address new technologies and user needs.
   
   
2. Understanding the Conformance Levels
   WCAG 2.1 introduces three conformance levels: A, AA, and AAA, which provide varying degrees of accessibility. These levels are hierarchical, with each subsequent level encompassing the requirements of the previous level. Let's explore each level in relation to color contrast.
   
   
3. Level A: Minimum Accessibility (Baseline)
   WCAG 2.1 Level A is the baseline conformance level. Meeting Level A criteria ensures a basic level of accessibility. Level A contains no contrast ratio requirement. What it does require, in 1.4.1 Use of Color, is that color is never the only means of conveying information, indicating an action or distinguishing an element. That is the first thing to check before measuring any ratios.
   
   
4. Level AA: Enhanced Accessibility (Standard)
   WCAG 2.1 Level AA is where the contrast requirements live, and it is the level that EN 301 549, the European Accessibility Act and the US rules require. 1.4.3 Contrast (Minimum) requires text and images of text to have a contrast ratio of at least 4.5:1 against their background, or at least 3:1 for large text (at least 18 point, or 14 point bold). 1.4.11 Non-text Contrast requires user interface components and the parts of graphics needed to understand the content to have a contrast ratio of at least 3:1 against adjacent colors. Logos, purely decorative elements and disabled controls are exempt.
   
   
5. Level AAA: Maximum Accessibility (Enhanced)
   WCAG 2.1 Level AAA represents the highest level of accessibility conformance. 1.4.6 Contrast (Enhanced) raises the text requirement to at least 7:1, or 4.5:1 for large text. There is no AAA criterion for non-text contrast. The W3C does not recommend requiring Level AAA for entire sites, because some content cannot meet every AAA criterion, but the enhanced ratio is worth adopting for body text where you can.
   
   
6. Importance of Color Contrast in Accessibility
   Color contrast is essential for individuals with low vision or color deficiencies to perceive and comprehend digital content effectively. Adequate color contrast ensures legibility and reduces eye strain, enabling users to navigate and consume information without barriers. By complying with WCAG 2.1 guidelines, designers and developers can create a more inclusive online environment for all users.
   
   
7. Tools and Techniques for Evaluating Color Contrast
   To meet WCAG 2.1 guidelines for color contrast, various tools and techniques are available to assess the contrast ratios between text, images, and backgrounds. Color contrast checkers, browser extensions, and design software plugins can help identify and adjust color combinations that do not meet the recommended ratios. Additionally, using proper typography, such as choosing fonts with high readability and appropriate sizes, can further enhance the legibility of content.

Ensuring color contrast accessibility is a crucial aspect of designing inclusive digital content. By adhering to WCAG 2.1 A, AA, and AAA guidelines, designers and developers can create websites and applications that are accessible to individuals with visual impairments. Implementing appropriate color contrast not only improves readability but also enhances the overall user experience for all users, regardless of their abilities. Let's strive to make the web accessible to everyone by embracing the principles of color contrast accessibility.