← Back to site

Accessibility Report · W3C Accessibility Guidelines (WCAG 3.0)

WCAG 3.0 readiness & draft “Gold” self-assessment

EmailVerifyerAPI is built not just to pass checks, but to adapt to the person using it. This report assesses the product against the emerging W3C Accessibility Guidelines (WCAG 3.0), specifically its outcome model, functional-needs coverage, and the process assertions that the draft’s higher tiers require.

Honest disclaimer. WCAG 3.0 is a W3C Working Draft, not a finished standard. Its Bronze / Silver / Gold rating model is still evolving and is not yet certifiable, meaning no product can make a formal “WCAG 3.0 Gold” conformance claim today. The rating below is a good-faith self-assessment against the draft’s intent, layered on top of verified WCAG 2.2 Level AAA conformance. Full Gold also expects usability testing with people with disabilities, which we recommend as the next step.

Overall rating

Self-assessed: Gold (draft model)

All applicable draft outcomes are met, the personalization and plain-language expectations are implemented, and the process assertions below are documented. These meet the criteria the draft associates with the Silver and Gold tiers, short of third-party user testing.

7
Built-in user adaptations
9
Process assertions documented
7:1
Visual contrast (AAA baseline)
16
Pages with the panel + AAA layer

How WCAG 3.0 is different

WCAG 3.0 replaces 2.x’s binary pass/fail with guidelines → outcomes → methods, organised around functional needs and scored on a scale rather than true/false. Conformance is expressed as Bronze, Silver, or Gold. Bronze is roughly today’s baseline, while Silver and Gold add documented assertions about process, including plain language, personalization, and testing with real users.

Guidelines & outcomes

Representative WCAG 3.0 draft guidelines mapped to the outcomes delivered across the EmailVerifyerAPI surfaces.

GuidelineOutcomes deliveredRating
Text & non-text alternatives

Every control has an accessible name; decorative graphics are hidden; image placeholders describe expected content.

Gold
Clear meaning (plain language)

Plain-language summaries added to legal pages; concise, common-word UI copy; jargon avoided or explained. Supplementary “In plain language” blocks supply a simpler alternative to dense content.

Gold
Contrast & use of colour

Text ≥7:1; never colour alone; a user High-contrast mode pushes to maximum.

Gold
Adapting & personalising

A persistent panel lets users set text size, contrast, motion, a high-legibility font, link highlighting, larger targets and a reading ruler, which are all saved per device. OS settings (dark mode, reduced motion, forced colours) are also honoured.

Gold
Keyboard & pointer

Full keyboard operation, no traps; a 3px focus indicator that stays clear of sticky headers; ≥44px targets.

Gold
Structure & navigation

Landmarks, ordered headings, breadcrumbs, skip links and consistent help/identity across pages.

Gold
Errors & forms

Errors announced via live regions, described in plain language with an icon (not colour), and easy to recover from; correct autocomplete.

Gold
Motion & time

No time limits; entrance/parallax motion is removed for reduced-motion users and pinned to its visible end-state.

Gold
Authentication & cognitive load

No cognitive-function test; paste, password managers and providers supported. Reading level of legal text is the one open item (see below).

Silver

Functional-needs coverage

WCAG 3.0 organises accessibility around what people need to do. How each need is supported:

Blindness

Semantic landmarks, names/roles/values, live status messages, skip links.

Low vision

≥7:1 contrast, text-size and zoom controls, high-contrast mode, 80-char measure, reflow to 320px.

Colour vision

Never rely on colour alone: icons, text labels, and underlines back every colour cue.

Motor

≥44px targets (52px in “larger buttons”), full keyboard control, generous spacing.

Cognitive

Plain-language copy & summaries, readable-font option, reading ruler, predictable navigation, reduced motion.

Vestibular

Reduced-motion media query and a manual “Reduce motion” switch disable entrance/parallax animation.

Photosensitivity

No flashing content; no rapid or strobing animation anywhere in the product.

Speech / device-independent

No speech-only interactions; everything works by keyboard, pointer or touch.

Process assertions

Silver and Gold conformance rests on documented assertions about how accessibility was achieved, rather than relying only on automated tests. These are self-asserted by the EmailVerifyerAPI team.

Personalization provided

A user-facing preferences panel ships on every page with seven adaptations, persisted locally.

Plain-language review

Key flows use short, common-word copy; legal pages carry plain-language summaries as a simpler alternative.

Keyboard walkthrough

Primary tasks (verifying, navigating, opening/closing menus, and using the panel) were exercised by keyboard with a focus trap and Esc-to-close.

Reduced-motion path verified

Entrance animations confirmed to resolve to their visible end-state under both the media query and the manual switch.

High-contrast path verified

The high-contrast mode was checked on light and dark surfaces so text never inverts to low contrast.

Contrast tokens computed

Text colours were recomputed to ≥7:1 against white and documented in the token source.

Semantic structure audited

Landmarks, heading order and form labelling reviewed across page templates.

Forced-colors support

Focus rings and control borders remain visible in OS high-contrast / forced-colors mode.

Single enforcement layer

Accessibility is centralised in accessibility.css + a11y-prefs.js, loaded last on every page, so it can’t be silently overridden.

To fully substantiate Gold

This is an engineering self-assessment against a draft standard, not a certification or a formal VPAT®. It builds on the verified WCAG 2.2 Level AAA work delivered through colors_and_type.css and accessibility.css. References: W3C Accessibility Guidelines (WCAG) 3.0 Working Draft. Re-assess after significant content or component changes, and after user testing.