WHY ENGLISH?
Turn an accessibility statement into a route to action
Use the routes to check scope, understand standards and testing, work around known barriers and report what still prevents a real task.
Open the full contents · See the How English Works hub
Full contents
Confirm the scope
Translate the promise
Read the evidence
Navigate barriers
Request improvement
Practice and next steps
Practice and next steps
Practice and next steps
A digital accessibility statement should help a person understand what a website, application or document can currently support, where barriers remain and how to get help. English matters because a confident commitment, a technical standard, a known limitation and a contact route do different jobs; merging them can make the statement comforting but unusable.
Readers search for accessibility statements, WCAG compliance, website accessibility and alternative formats when a digital service blocks a task. The best reading method begins with the user's need: which content or function is in scope, which barrier is known, what alternative is available now and who owns the response.
The W3C Web Accessibility Initiative's guidance on developing an accessibility statement says a statement should at least include a commitment, the standard applied and contact information, and advises including known limitations, measures taken, technical prerequisites and testing environments. Singapore's current Digital Service Standards overview describes accessible government services through operable, perceivable, robust and understandable principles. A statement is not automatically a technical assessment or legal declaration of conformity.
Use the statement map owner, service, scope, platform, date, version, commitment, standard, level, status, limitation, affected user, task, content, alternative, workaround, browser, device, assistive technology, testing, user research, third party, document, media, form, keyboard, contrast, text alternative, contact, response, escalation, roadmap, target date and update. The goal is to turn the statement into a practical route through the service.
Identify the service owner
Orient the statement around the organisation responsible for the statement and digital service. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when a familiar logo is assumed to identify the accountable party.
Check the current page and check the official domain, owner and contact context.
Access example. A public-service page and an embedded payment service have different owners Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why the organisation responsible for the statement and digital service deserves a traceable decision rather than a quick impression.
Check the statement date
Translate when the information was reviewed or updated from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when a permanent footer link is assumed to contain current facts.
Name the barrier's effect and record the date and look for a revision note.
User scenario. A redesign after the statement date may add features and new barriers The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Define the digital scope
Evaluate the websites, applications, subdomains, portals and documents covered as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when one statement is assumed to include every related service.
Look for dates, methods and list included and excluded properties.
Testing example. The main information site is covered while a legacy booking portal has a separate statement The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Separate commitment from current status
Use the promise to improve versus the accessibility achieved today to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when supportive language is read as proof that every function works.
Compare the alternative with the original route and find the concrete status and limitations after the commitment.
Service example. An organisation can care deeply while a video archive still lacks captions The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Identify the standard
Orient the statement around the named accessibility standard and version used. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when WCAG is mentioned without a version or role.
Check the current page and record the exact reference and any stated level.
Access example. WCAG 2.2 is not interchangeable with a vague claim of following best practice Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why the named accessibility standard and version used deserves a traceable decision rather than a quick impression.
Read the conformance claim cautiously
Translate whether the statement claims full, partial or another described status from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when a badge is treated as legal or universal certification.
Name the barrier's effect and check scope, evidence, exceptions and jurisdiction.
User scenario. A statement describes alignment for tested pages but excludes a third-party map The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Remember what the statement is not
Evaluate the boundary between user information, testing report and legal declaration as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when the page is used as the only accessibility evidence.
Look for dates, methods and look for linked audits and testing information where relevant.
Testing example. A plain-language limitation helps users even though it is not a technical conformance report The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Read known limitations first
Use the barriers the owner already recognises to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when limitations are dismissed as defensive boilerplate.
Compare the alternative with the original route and match each limitation to user, task and content.
Service example. A keyboard trap in a date picker affects booking even if most text pages work The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Translate technical barriers
Orient the statement around the practical effect of a success-criterion failure. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when a criterion number is assumed to explain the user experience.
Check the current page and rewrite it as the task a person cannot complete.
Access example. Missing labels mean a screen-reader user may not know what a form field requests Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why the practical effect of a success-criterion failure deserves a traceable decision rather than a quick impression.
Look for an immediate alternative
Translate the accessible route available while repair is pending from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when a future fix date is treated as help today.
Name the barrier's effect and find alternate format, channel or assisted process.
User scenario. A phone-assisted booking route supports the current transaction while the form is repaired The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Check whether the alternative is equivalent
Evaluate access to the same information, action and timing as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when any other channel is assumed sufficient.
Look for dates, methods and compare cost, hours, privacy and outcome.
Testing example. A weekday phone line may not equal a 24-hour online deadline The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Read contact instructions
Use what information helps the owner reproduce and resolve a barrier to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when users are told only to contact us.
Compare the alternative with the original route and note channel, page, task, device and preferred response format.
Service example. A report names the inaccessible PDF and requests an HTML alternative The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Protect privacy in a barrier report
Orient the statement around the minimum personal or disability information needed for support. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when the user is expected to disclose a diagnosis.
Check the current page and describe the barrier and accommodation need without unnecessary detail.
Access example. A user requests keyboard access without sharing medical history Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why the minimum personal or disability information needed for support deserves a traceable decision rather than a quick impression.
Check response expectations
Translate whether acknowledgement, assistance or target times are stated from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when a contact address is assumed to promise immediate resolution.
Name the barrier's effect and separate stated commitment from personal expectation.
User scenario. The statement promises acknowledgement in two working days but gives no repair deadline The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Find escalation or complaint routes
Evaluate the next step if the barrier or response remains unresolved as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when every jurisdiction is assumed to use the same enforcement path.
Look for dates, methods and follow the statement and applicable local framework.
Testing example. A public body links a formal complaint route while a private site provides service escalation The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Read testing methods
Use automated scans, expert review, manual tests and user testing described to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when one tool score is treated as complete accessibility.
Compare the alternative with the original route and identify which methods and dates support the claim.
Service example. An automated scan is supplemented by keyboard and screen-reader tasks The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Check user involvement
Orient the statement around whether people with disabilities or older users participated in testing. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when technical compliance is assumed to reveal every usability barrier.
Check the current page and look for scenarios, participant range and improvement loop.
Access example. Actual users identify a confusing timeout that a code scan cannot see Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why whether people with disabilities or older users participated in testing deserves a traceable decision rather than a quick impression.
Check browsers and devices
Translate the platforms on which the service was tested or expects to work from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when one successful browser is generalised to every environment.
Name the barrier's effect and compare the user's setup with stated coverage.
User scenario. A mobile browser problem may sit outside a desktop-only test record The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Check assistive technology
Evaluate screen readers, magnifiers, voice control or other tools named as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when compatibility with one product is read as compatibility with all.
Look for dates, methods and record versions and test conditions where provided.
Testing example. The statement identifies a known issue with one browser-screen-reader combination The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Check keyboard operation
Use whether functions can be reached and used without a pointer to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when tab focus is assumed to prove full operation.
Compare the alternative with the original route and test order, visibility, controls and escape paths.
Service example. A menu receives focus but cannot be opened from the keyboard The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Check text alternatives
Orient the statement around how images, charts and non-text content convey meaning. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when the presence of alt text is assumed to make it accurate.
Check the current page and compare description with the image's purpose.
Access example. A chart needs the trend and values, not merely alt text saying chart Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why how images, charts and non-text content convey meaning deserves a traceable decision rather than a quick impression.
Check headings and structure
Translate whether content relationships are available visually and programmatically from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when large bold text is assumed to be a heading.
Name the barrier's effect and look for logical levels and landmark navigation.
User scenario. A screen-reader user can move from section to section without reading every line The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Check colour and contrast
Evaluate whether information remains perceivable without colour alone and at sufficient contrast as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when brand colours are assumed accessible in every combination.
Look for dates, methods and look for stated limitations and practical alternatives.
Testing example. An error uses an icon and text as well as a red border The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Check forms and errors
Use labels, instructions, validation and recovery from mistakes to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when a visible message is assumed to be announced to assistive technology.
Compare the alternative with the original route and trace the full submission task.
Service example. An error summary links back to each field and explains how to repair it The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Check status messages
Orient the statement around updates that appear without moving focus. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when visual change is assumed to reach every user.
Check the current page and look for programmatic announcement and plain meaning.
Access example. A search result count is announced after filters change Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why updates that appear without moving focus deserves a traceable decision rather than a quick impression.
Check documents and PDFs
Translate downloaded files, forms and archived documents inside or outside scope from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when an accessible webpage is assumed to make every attachment accessible.
Name the barrier's effect and look for tagged files or alternative formats.
User scenario. A scanned notice is paired with a structured HTML version The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Check audio and video
Evaluate captions, transcripts, audio description and controls as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when automatic captions are assumed accurate.
Look for dates, methods and read which media are covered and how errors can be reported.
Testing example. A lecture video has corrected captions and a transcript with speaker labels The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Check third-party content
Use widgets, maps, payment tools and embedded services the owner does not fully control to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when third party becomes an excuse with no route forward.
Compare the alternative with the original route and look for responsibility, alternative and supplier follow-up.
Service example. An inaccessible map is paired with text directions while the vendor issue is tracked The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Read the remediation roadmap
Orient the statement around which barriers will be fixed, by whom and on what target. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when a date is treated as a guarantee regardless of dependencies.
Check the current page and separate commitment, target and completed evidence.
Access example. A document backlog is prioritised by public need and tracked by quarter Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why which barriers will be fixed, by whom and on what target deserves a traceable decision rather than a quick impression.
Check how updates are governed
Translate the trigger and owner for revising the statement from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when the page remains static after product changes.
Name the barrier's effect and look for review cadence and change events.
User scenario. A major redesign triggers new testing and a statement revision The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Compare statement with experience
Evaluate the difference between published status and the barrier a user actually meets as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when a contradiction is treated as proof of bad faith.
Look for dates, methods and report the reproducible task and seek resolution.
Testing example. A newly introduced focus problem is documented with page, control and browser The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Use the statement to choose action
Use the practical next move: continue, use an alternative, contact, escalate or wait for repair to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when the statement is read as public-relations copy only.
Compare the alternative with the original route and translate each relevant line into a user route.
Service example. A user downloads an accessible format now and subscribes to the repair update The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Check language and reading level
Orient the statement around whether the statement itself can be understood by the people who need it. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when standards jargon replaces a clear explanation of the barrier and next action.
Check the current page and prefer short sentences, defined terms and task-based headings.
Access example. A user can find the contact route without first decoding an audit vocabulary Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why whether the statement itself can be understood by the people who need it deserves a traceable decision rather than a quick impression.
Read document accessibility scope
Translate whether PDFs, forms, captions and downloadable files are included from technical language into a human task. Accessibility exists at the point where someone can perceive, operate and understand the service.
Meaning disappears when an accessible webpage is assumed to make every linked document accessible.
Name the barrier's effect and test the document needed for the task and look for an alternative format route.
User scenario. A policy page works with a screen reader but its scanned application form still requires remediation The limitation is now understandable without specialist vocabulary.
Keep the technical reference for verification, but let plain language lead the user route.
Check mobile and orientation limits
Evaluate whether touch targets, reflow, zoom and screen orientation support the task as evidence, not decoration. A statement should reveal how the organisation knows what it claims.
Confidence is overstated when desktop testing is presented as evidence for every device.
Look for dates, methods and compare the statement's test environment with the user's actual path.
Testing example. A booking flow is readable on desktop yet a fixed mobile panel hides the final confirmation button The claim gains a visible boundary.
Ask which users, tasks or technologies may still sit outside the evidence.
Assess third-party components
Use the payment, map, identity or embedded service that sits inside the user journey to restore agency. When a barrier exists, the statement should help a person complete the task or obtain assistance.
Help fails when the site owner excludes a dependency without giving the user a route forward.
Compare the alternative with the original route and identify ownership while keeping one practical support path for the whole task.
Service example. A council directs a payment-widget barrier to the supplier internally while the resident contacts one public service desk The user can act while repair remains accountable.
Record the owner, response route and update point so the issue does not disappear.
Look for an update commitment
Orient the statement around the date or event when known limitations and remediation progress will be reviewed. A user first needs to know whether the words apply to the service and task in front of them.
The route becomes unreliable when the statement records a barrier but never indicates when information may change.
Check the current page and note the owner, target or review date and verify later status.
Access example. A statement distinguishes a planned caption repair from a permanent alternative transcript service Scope becomes a practical instruction rather than fine print.
Did You Know? W3C advises that accessibility statements use simple user-focused language and include a commitment, the applied standard and contact information, with known limitations and testing context where useful. This is why the date or event when known limitations and remediation progress will be reviewed deserves a traceable decision rather than a quick impression.
A worked example
A student using only a keyboard reaches an online scholarship form but cannot open the date picker. The accessibility statement says the service follows WCAG, lists the date picker as a known limitation and provides an assisted application channel.
The student records the page, control, browser and task, uses the alternative before the deadline and reports the barrier without disclosing unnecessary health information. The service team acknowledges the issue and supplies a direct accessible method.
The statement has not removed the barrier, but precise English has reduced uncertainty: current status, immediate alternative, owner and repair route are visible. The user can act while the organisation remains accountable for improvement.
A practical checklist
- Official service owner confirmed
- Statement date and version checked
- Websites, apps and documents in scope mapped
- Commitment separated from current status
- Standard and claimed level recorded
- Known limitations translated into user tasks
- Immediate alternatives tested for equivalence
- Contact and escalation routes found
- Testing methods and environments understood
- Third-party content handled
- Remediation targets read as targets
- Barrier report protects privacy and preserves evidence
Advice for students, parents and young adults
Students can compare two real accessibility statements using columns for scope, standard, known barriers, alternative route, contact and update date. The goal is to see which statement helps a user act.
Parents can encourage children to describe the blocked task rather than saying the whole website does not work. Page, control, device and intended outcome give support teams a better starting point.
Organisations should involve people with disabilities, accessibility specialists, content owners, developers and service teams. A statement should be honest and useful, but it does not replace accessible design, testing or applicable legal duties.
Frequently asked questions
Does an accessibility statement prove a website is fully accessible?
No. It communicates commitments, standards, status, limitations and help routes. Check scope, evidence, date and actual user experience.
What is WCAG?
The Web Content Accessibility Guidelines are international recommendations from W3C for making web content more accessible. Read the version and stated level.
Why list known limitations publicly?
It helps users avoid surprise, find alternatives and report barriers, while giving the organisation a visible improvement obligation.
Is automated testing enough?
No. Automated tools find some issues. Manual, assistive-technology and user testing reveal other barriers.
What should a barrier report include?
Include the page or feature, task, what happened, device or browser when relevant, and the accessible outcome needed. Avoid unnecessary personal details.
What if the alternative is slower or unavailable?
Explain why it is not equivalent, ask for a workable accommodation and use the stated escalation or complaint route where appropriate.
The deeper English lesson
Accessibility-statement English is access-route language. Scope shows where the promise applies, plain descriptions translate technical failures into human tasks, alternatives restore agency, and dated limitations make improvement visible. Clear language is itself part of accessibility.
Useful next reading
Continue with reading a public consultation paper, reading a data privacy notice, writing a post-event evaluation, reading a university course registration guide, and the How English Works.