Accessibility statement
TL;DR.
This lecture discusses the critical role of accessibility statements in promoting inclusivity on websites. It outlines their purpose, key elements, and best practices for implementation to ensure all users, especially those with disabilities, can navigate effectively.
Main Points.
Importance of Accessibility Statements:
They set clear expectations and demonstrate commitment to inclusivity.
They foster trust by being transparent about accessibility efforts.
They serve as a competitive advantage in the digital landscape.
Key Elements:
Clear commitment to accessibility and available support.
Transparency about current accessibility status and known limitations.
Encouragement of user feedback for continuous improvement.
Operational Use:
Regular updates aligned with website changes and audits.
Clear contact pathways for reporting issues and requesting help.
Testing discipline to ensure ongoing compliance and usability.
Legal Compliance:
Adherence to WCAG standards is essential for accessibility.
Documenting efforts and plans helps prevent potential lawsuits.
Regularly updating the statement maintains compliance and user trust.
Conclusion.
Accessibility statements are vital for fostering an inclusive digital environment. By clearly communicating commitment to accessibility, organisations can enhance user experience, build trust, and position themselves as leaders in social responsibility. Regular updates and user engagement are crucial for maintaining the relevance and effectiveness of these statements, ensuring that all users feel valued and included in the digital space.
Key takeaways.
Accessibility statements are essential for demonstrating commitment to inclusivity.
They should clearly outline the scope, limitations, and support available to users.
Regular updates and transparency enhance user trust and engagement.
Compliance with WCAG standards is crucial for legal and ethical responsibilities.
Encouraging user feedback fosters a collaborative approach to accessibility improvements.
Accessibility statements should be easily accessible and written in plain language.
Documenting efforts and plans helps mitigate legal risks and showcases commitment.
Engaging users with disabilities in the process provides valuable insights.
Regular audits and testing ensure ongoing compliance and usability.
Promoting awareness of the accessibility statement enhances user understanding and engagement.
Play section audio
Understanding accessibility statements.
Purpose and expectation.
An accessibility statement is a public-facing document that explains how an organisation supports people who may experience barriers when using its website or digital service. It sets expectations, communicates intent, and signals that inclusion is treated as a real operational concern rather than a vague aspiration. When written well, it clarifies what has been done, what still needs work, and how users can get help when something does not function for them.
The statement works as a trust mechanism because it removes guesswork. Instead of forcing visitors to silently struggle, it acknowledges that different users browse in different ways, such as with screen readers, keyboard-only navigation, voice control, magnification, reduced motion settings, or alternative input devices. It also signals that accessibility is considered part of quality, similar to security, uptime, or performance, not an optional add-on.
In practice, accessibility statements often combine three responsibilities: describing the current level of accessibility, explaining support routes, and inviting feedback. That combination matters because accessibility is never purely technical. Even if a site aims for a specific standard, real-world usability still depends on content structure, design decisions, platform constraints, third-party widgets, and ongoing publishing habits. A statement helps align those moving parts into a single, accountable narrative.
Accessibility statements have become common across public sector bodies, education providers, and growing numbers of private organisations because they sit at the intersection of ethics, experience, and risk management. In many jurisdictions, they also link to legal compliance expectations, often referencing the WCAG framework. Even when not legally required, publishing a statement tends to improve internal discipline: teams become more likely to document decisions, test key journeys, and treat accessibility bugs as real defects rather than “nice to have” improvements.
There is also a strategic angle that does not rely on marketing language. A website that is easier to use for people with disabilities is usually easier to use for everyone. Clear headings support scanning, strong contrast helps mobile users in sunlight, keyboard navigation benefits power users, and descriptive links reduce confusion for all visitors. When an accessibility statement describes these efforts, it often correlates with better overall user experience, improved content clarity, and fewer support requests driven by preventable friction.
Organisations also use accessibility statements to create shared understanding across roles. A founder may focus on brand reputation and customer trust, while an operations lead thinks about support volume and process, and a web lead worries about platform limitations or release cycles. A statement provides a single artefact that can anchor all those perspectives: what matters, what “good” looks like, and what the next improvements should be.
Key elements of an accessibility statement.
Clear commitment to accessibility
Information on support available
Transparency about current accessibility status
Encouragement of user feedback
Scope and limitations.
An effective statement defines its scope with precision. “This website is accessible” is too broad to be useful, especially for organisations running multiple subdomains, microsites, embedded tools, or separate help centres. Scope clarifies what the statement covers, such as the marketing site, the online shop, the account area, a documentation portal, or a client login. It can also specify whether it includes downloadable files like PDFs, embedded videos, and transactional flows such as checkout or booking.
Equally important is honest discussion of limitations. Accessibility is an ongoing engineering and content practice, not a one-time tick-box task. Organisations should avoid claiming full compliance unless they can demonstrate it with evidence such as recent audits, testing notes, or documented fixes. A credible statement may say that most pages follow a target standard, while certain areas remain in progress due to platform constraints, legacy content, or third-party dependencies.
Known limitations often arise from elements outside direct editorial control. Third-party tools can introduce issues that are difficult to remediate without replacing the vendor. Examples include cookie banners that trap keyboard focus, booking widgets with poor labelling, chat tools that are unreadable at high zoom, payment flows that fail screen reader navigation, or embedded maps that do not provide equivalent text alternatives. Stating these limitations upfront helps users plan workarounds and helps the organisation prioritise replacement or mitigation.
Platform reality also matters. Tools such as Squarespace provide strong foundations, but templates, blocks, and custom code can still create accessibility gaps if not managed carefully. For instance, a visually attractive layout may rely on images that contain important text, which becomes inaccessible if no equivalent text exists. A complex animation might look polished but can be uncomfortable for users who prefer reduced motion. Scope statements can explain how the organisation handles these patterns, such as avoiding text-in-image for critical content, providing captions and transcripts, or respecting reduced motion settings where possible.
Browser and device variation deserves a short, factual acknowledgement. Accessibility behaviour can differ between Safari and Chrome, between iOS and Android, and across assistive technologies. For example, a menu may be keyboard-navigable on desktop but behave differently on mobile screen readers. A statement that recognises this variability avoids overpromising and points users towards the fastest support route if a specific combination breaks.
Keeping the statement current is part of its credibility. Regular reviews prevent the common failure mode where a statement claims improvements that are no longer accurate after a redesign, a plugin update, or new content publishing habits. Many teams schedule a quarterly review, and trigger ad-hoc updates after major template changes, checkout adjustments, or the introduction of new third-party widgets.
Input from people with disabilities strengthens the statement and the underlying work. User feedback often reveals barriers that automated checks miss, such as confusing focus order, misleading link labels, unclear error messages, or interactions that require precise pointer control. When that feedback is reflected in the statement, it signals that accessibility is informed by real experience, not only by compliance tooling.
For teams that need a practical mechanism to support continuous improvement, periodic accessibility audits help. These can be internal reviews using checklists and assistive tech spot checks, or external assessments that document issues by severity and effort. The key is traceability: the statement should remain aligned with the real state of the site, even when that state includes imperfections and work in progress.
Addressing known limitations.
Identify specific sections covered
List known accessibility barriers
Clarify third-party tool impacts
Communicate ongoing efforts for improvement
Contact pathway.
A clear contact pathway is the operational backbone of an accessibility statement. It gives users a practical next step when something fails, and it gives the organisation a repeatable workflow for triage and remediation. Without a reliable pathway, even a well-written statement becomes performative because users are left with no way to resolve blockers in the moment.
The contact guidance should specify what information helps speed up diagnosis. Useful details usually include the page URL, device model, operating system, browser, assistive technology (such as NVDA, JAWS, VoiceOver, TalkBack, Dragon, or a keyboard-only setup), and a short description of what the user expected versus what happened. This turns vague reports into actionable tickets. For example, “checkout button cannot be reached with Tab in Safari on macOS” is immediately more solvable than “site is broken”.
Response expectations also matter. Users reporting accessibility problems are often blocked from completing a task, not merely offering suggestions. Setting a realistic response target, such as acknowledging requests within a certain number of business days, helps build confidence. If the organisation cannot offer fast fixes, it can still offer fast acknowledgement plus a workaround, such as an alternative method to complete a booking, request a quote, or access a document.
The contact method itself must be accessible. If a site only offers a small, low-contrast web form that times out, the pathway fails the people it is meant to support. Many organisations provide multiple channels, such as email and phone, and sometimes a simple form that has been tested with keyboard navigation and screen readers. The goal is not to offer every channel possible, but to offer at least one channel that works reliably across common access needs.
Internally, routing and ownership should be explicit. Accessibility reports often get lost when they land in a generic inbox with no accountable responder. A strong process assigns a responsible owner, tracks issues as tickets, and categorises themes such as navigation, forms, media, contrast, or third-party embeds. This allows recurring problems to be fixed at the source, reducing future reports and support load.
A feedback loop can strengthen engagement without becoming noisy. When a fix is deployed, users who reported the issue can be informed that the change has been made, sometimes with a request to confirm whether it resolves the problem. This creates a sense of collaboration and signals that reports lead to action. It also reduces duplicate reporting because users learn that there is a functioning mechanism.
Staff readiness is a hidden multiplier. Teams handling accessibility queries benefit from short training on respectful language, common assistive technology patterns, and how to gather technical details without putting the burden on the user. Even a small script or checklist can raise the quality of responses and reduce the time-to-fix. Where budgets allow, a dedicated accessibility owner or small working group can keep priorities visible across design, content, and development.
Technology can support the pathway when it is used carefully. Some organisations introduce an on-site help layer that guides users to the right resource, collects the right diagnostic fields, and reduces repetitive back-and-forth. Where that approach fits, tools like CORE can function as a front-line knowledge layer for common accessibility questions and known workarounds, while still escalating unresolved issues to a human owner. The intent should remain user support, not deflection.
With scope defined and a working contact pathway in place, the statement becomes a living part of operations rather than a static page. The next step is ensuring the statement aligns with real testing routines and content publishing habits, so accessibility stays resilient as the site evolves.
Facilitating user feedback.
Provide accessible contact methods
Specify required information for reporting
Set response expectations
Track and address recurring issues
Play section audio
Scope and limitations.
Define what parts of the site are covered.
An accessibility statement works best when its scope is explicit. Rather than implying that “the website” is one uniform thing, it should specify exactly which digital surfaces are included, such as all public pages, logged-in areas, checkout flows, knowledge bases, and any interactive tools. This prevents confusion when someone encounters a section that behaves differently (for example, a booking widget that cannot be used with a keyboard) and needs to know whether that area is covered by the same accessibility approach.
In practice, many businesses operate more than one web property, and coverage is rarely identical across them. A brand might run a main marketing website, a help centre on a subdomain, and a separate customer portal. If those properties live on separate domains or are maintained by different teams, each one may need its own statement or at least a clearly separated subsection. That structure avoids vague promises and helps set accurate expectations about where accessibility work has been completed versus where it is still in progress.
Coverage should also account for how people actually access content. A site may look fine on desktop, yet behave differently on mobile due to navigation patterns, sticky headers, modals, or responsive layout changes. Stating that the statement applies to experiences on mobile, tablet, and desktop clarifies that accessibility is being considered across breakpoints, not only in one “ideal” environment. If there are known differences by device class, naming them here helps users choose the route that will be most workable for their situation.
Where the site uses multiple systems, naming them can make the statement more useful without turning it into a developer document. For example, a Squarespace marketing site might embed a client portal, a form provider, and a commerce checkout. Calling out these components (even at a high level) helps users and internal teams align on what “the site” includes. It also creates a practical checklist for future audits, because the statement becomes a living inventory of the experiences that must be tested and improved.
Identify known limitations candidly.
An honest statement should acknowledge known limitations without defensiveness. Accessibility is rarely perfect, especially for older pages, legacy templates, or content produced quickly under marketing deadlines. Naming issues like missing captions, incomplete image descriptions, insufficient colour contrast in a specific component, or inconsistent focus states in navigation makes the statement credible. It signals that the organisation is paying attention to real user barriers, not only compliance language.
Clarity improves when limitations are described in terms of impact. Instead of only listing what fails a standard, the statement can explain what might happen during use. A missing caption affects people who are Deaf or hard of hearing, but it can also affect someone in a noisy environment or a user who prefers to read. A carousel that traps keyboard focus may block someone from reaching a purchase button. This kind of explanation turns a technical deficit into a practical warning that helps people navigate around it.
Where possible, the statement can offer workarounds that do not place undue burden on users. If a document is not accessible, an accessible HTML alternative can be offered. If a map embed is difficult to operate, the same address details can be provided in text with a clear link to directions. If a key interaction fails with keyboard navigation, a contact route can be provided that gets the person to the same outcome, such as booking via email or requesting a call back. The goal is not to justify the barrier, but to reduce its harm while the fix is being delivered.
It helps to connect limitations to prioritisation. Some issues block task completion (like paying, signing up, or submitting a form) and should be treated as high severity. Others are inconvenient but not fully blocking (like minor heading structure inconsistencies). Calling out that the team prioritises blockers first creates a coherent logic for improvement and reduces the sense that problems are being ignored. It also makes it easier for stakeholders to allocate resources rationally, because there is a visible link between user impact and the order of fixes.
Note third-party tools that may affect accessibility.
Modern websites often rely on third-party tools for forms, scheduling, chat, video, payments, analytics overlays, and embeds. These tools can introduce accessibility barriers even when the core website is carefully built. An accessibility statement should name the types of third-party services in use and explain that some limitations may originate from those providers. This is not about shifting responsibility, it is about giving users accurate information and acknowledging the real technical boundary between what the site owner controls and what they can influence.
Third-party issues commonly show up in keyboard behaviour, focus management, and screen reader announcements. A pop-up widget might open without moving focus to the dialog. A video player might not expose controls properly to assistive technology. A booking calendar might rely on hover interactions that do not translate well to keyboard-only use. Stating that these elements are being monitored and improved, and that alternatives are available on request, helps users avoid dead ends.
It is also useful to describe compatibility at a general level with assistive technologies such as screen readers, browser zoom, voice dictation, and keyboard-only navigation. The statement does not need to become a lab report, but it can indicate the environments most commonly tested. For instance, the organisation might regularly test the latest versions of major browsers and one or two leading screen readers, then commit to investigating reports that involve other tools. That framing sets expectations while still welcoming feedback from users with different setups.
Where an external provider publishes its own accessibility documentation, linking to it is practical. It gives users a direct reference point, and it gives internal teams a way to compare provider claims with observed behaviour. If a tool consistently fails accessibility needs, noting that the organisation is evaluating alternatives can be appropriate, provided it is truthful and does not promise a timeline that cannot be met.
Mention that accessibility is an ongoing effort.
Accessibility should be framed as an ongoing operational practice, not a one-off compliance deliverable. A good statement explains that the organisation performs regular checks, responds to feedback, and updates content and components as the site evolves. This matters because websites are living systems. New landing pages, seasonal campaigns, plugin updates, and layout refreshes can introduce fresh issues even when earlier pages were improved.
One of the most effective ways to sustain progress is to embed accessibility into routine workflows: content publishing checklists, design reviews, and release processes. That means alternative text is treated as part of the publishing task, not a separate “later” job. It also means interactive components are tested for keyboard access before they ship, not only after complaints arrive. When a statement hints at these habits, it signals that accessibility is being built into how the team works, rather than being handled as occasional clean-up.
Feedback channels are part of this commitment. The statement should explain how people can report accessibility problems, ideally offering more than one contact method. A short form can work well if it is accessible, but an email option can be essential for users who cannot complete a form due to the very barrier they are trying to report. If the organisation can share typical response times, that can help users plan, but it should only do so if it can realistically meet the expectation.
Some organisations also publish a lightweight roadmap: what is being improved next and what is under review. Even a short list can create accountability and reduce repeated queries. It can also guide internal prioritisation by making accessibility visible as a product and operations concern, not simply a design preference.
Keep language plain and non-technical where possible.
An accessibility statement is primarily a communication tool, so it should use plain language and avoid heavy jargon. When technical terms are necessary, they should be briefly explained in simple words. For example, mentioning WCAG can be useful, but only if the statement also explains what it means in practical terms, such as aiming for content that can be navigated with a keyboard, read by screen readers, and understood with clear structure and contrast.
Clear language also reduces the risk of overpromising. Absolute claims like “fully accessible” are hard to defend unless the organisation has strong evidence, continuous testing, and strict controls over third-party tools. A more accurate approach is to state what the organisation is working towards, what has already been improved, and where limitations remain. This tone feels trustworthy because it matches how websites are actually built and maintained.
Plain-English writing can still include concrete examples that help users self-serve. Instead of only saying “we support keyboard navigation”, the statement can mention that menus, buttons, and forms can be used without a mouse. Instead of only saying “we use headings correctly”, it can explain that pages are structured so screen reader users can jump through sections quickly. These examples teach without sounding like policy text.
When the statement reflects real scope, candid limitations, third-party constraints, and ongoing improvement practices, it becomes more than a compliance page. It becomes a practical guide that helps people succeed on the site, while also guiding internal teams towards measurable accessibility maintenance as the next part of their digital work.
Play section audio
Contact pathway.
Reporting issues and requesting help.
A usable accessibility programme depends on a clear contact pathway that people can find quickly, understand instantly, and use without friction. When a user hits a barrier, the organisation’s job is to offer a simple way to report the problem and request assistance, without forcing extra steps that may be difficult for someone using assistive technology or dealing with cognitive overload. A dedicated accessibility contact route also signals intent: accessibility is not treated as a legal checkbox, but as an operational commitment.
A practical starting point is a purpose-built contact form solely for accessibility queries. This is not the same as a generic “Contact us” form. It should route to the right owners (such as web lead, product, or operations), capture the right triage data, and avoid being buried in a marketing funnel. On a Squarespace site, this often means creating an “Accessibility help” page with a focused form and linking it consistently across the site. When forms are designed for clarity, users can report issues quickly, and the team receives structured data that is easier to action than a freeform message.
Multiple channels are still important because accessibility needs vary. Some users are comfortable with a form, others prefer email because it allows attachments or longer context, and some need a real-time option. A dedicated email address for accessibility support can sit alongside the form so users can choose the path that matches their situation. If a phone option is offered, it should not be treated as a token gesture: it should be staffed or monitored, and the site should describe when it is available. Time zones matter for global audiences, and “call us” without hours and expectations tends to create frustration rather than trust.
Visibility is part of accessibility. If the only link to accessibility support sits on a hard-to-find policy page, users will default to abandoning the task. Placing the accessibility contact link in the footer, adding it to a help centre, and referencing it in an accessibility statement reduces search time and lowers stress at the moment the barrier appears. Some organisations also include a short “Need help?” component on high-risk pages such as checkout, login, account settings, and form-heavy pages, because those areas often trigger the most urgent issues.
Short self-serve content can reduce needless back-and-forth without pushing responsibility onto users. A compact FAQ that answers common issues (for example keyboard navigation, PDF access, captions, contrast mode, or account access) can help in the moment. The aim is not to replace reporting; it is to reduce repeated enquiries and speed up resolution for urgent cases. Where a site already uses an on-site help layer, a search concierge such as CORE can also route users to the right guidance instantly, but the organisation should still retain a clear human escalation path for unresolved barriers.
Accessibility of contact methods.
Every support channel must be accessible in its own right, otherwise the organisation creates a loop where the user cannot report the very barrier they are experiencing. A web form should work with screen readers, have properly associated labels, clear field purpose, and predictable focus order. Error messaging should be specific and recoverable, meaning it should explain what went wrong and how to fix it without wiping the form. If the form uses a captcha, the organisation should confirm it has an accessible alternative, because many captcha patterns create hard stops for users with low vision, dyslexia, or motor impairments.
Keyboard-only operation is a non-negotiable baseline. The form should allow users to tab through fields, select dropdowns, tick checkboxes, and submit successfully without a mouse. Visible focus states are essential so users can see where they are on the page. Contrast and typography should support readability: high contrast between text and background, legible font sizing, and sufficient spacing so the interface does not feel “dense” or tiring. These are small design decisions, but they directly affect whether a person can ask for help at all.
Alternative channels should be planned, not improvised. If a phone number is offered, the organisation should consider deaf and hard of hearing access. That may involve supporting relay services where available, and clearly stating what is supported. Where sign language is a relevant need, a video relay service can remove a major barrier, but it should be positioned as part of an intentional support design rather than an afterthought. Live chat can also be helpful, yet it can fail accessibility basics if it traps focus, times out, or relies on non-semantic components. If chat is offered, it should be tested with screen readers and keyboard navigation, and it should allow transcripts or follow-up via email.
Testing should include real assistive technology usage, not just automated scans. Automated tools catch some issues (missing labels, contrast problems), but they do not reflect the lived experience of navigating a form with a screen reader, magnification, voice control, or switch device. Regular usability testing with disabled users is often where the most valuable findings appear, such as confusing field wording, unclear confirmation states, or a submit button that is technically present but practically hard to activate. When testing is scheduled as a recurring workflow, contact methods stay functional as the site evolves.
Information for effective triage.
Accessibility reports are most useful when they include enough context for fast diagnosis. The goal of triage is not to interrogate users; it is to minimise the number of follow-up questions and shorten the time between report and fix. When a report arrives with the page location, environment details, and a plain description of what happened, the team can reproduce the issue, determine severity, and assign the right owner without delay.
The contact form can gently prompt for key details that materially improve debugging. A simple set of fields often outperforms an open text box because it nudges consistent reporting while still allowing nuance. Typical essentials include the page URL, what the user was trying to do, what went wrong, and what they expected to happen. Environment information matters because many accessibility problems are browser-specific or device-specific, especially issues related to focus handling, sticky headers, overlays, and embedded third-party widgets.
Assistive technology context is frequently the difference between “cannot reproduce” and “fixed today”. If the user can share the tool they are using, the team can validate behaviour in similar conditions. This can include screen readers, magnifiers, voice dictation tools, alternative keyboards, or browser accessibility settings. The form should not assume users know technical names, so it can offer examples in plain language (for example “Voice control such as dictation”, “Screen reader”, “Text enlargement”, “Keyboard only”) while still allowing a free text option.
Providing a short guide near the form helps users supply what matters without feeling burdened. A “What to include” panel can clarify that the organisation does not need personal details, but does need reproduction information. For businesses managing multiple sites, products, or templates, this structure becomes even more valuable because it turns reports into actionable work items rather than vague complaints.
A checklist format can work well because it reduces cognitive load and improves completeness:
Page URL (copy and paste the address)
Device type (mobile, tablet, desktop)
Operating system (such as iOS, Android, Windows, macOS)
Browser and version (such as Chrome, Safari, Firefox)
Description of the barrier and what task was blocked
Assistive technology or accessibility settings in use
Screenshot or short screen recording if the user can provide one
Once this data is collected, categorisation becomes easier. A lightweight tagging approach can separate issues by type (keyboard navigation, contrast, missing text alternatives, form labelling, video captions), severity (blocks task completion versus minor friction), and scope (single page versus site-wide component). For teams using automation platforms such as Make.com, these form submissions can be routed into a tracker automatically, tagged, and assigned to the correct queue, reducing manual handling while keeping accountability intact.
Response expectations.
Clear response expectations reduce uncertainty and make the organisation feel reliable, even before a fix is delivered. When users report an accessibility barrier, they are often already frustrated. A simple statement about expected timelines and next steps can prevent the experience turning into distrust. The message should focus on what the organisation will do, not on policies that shift responsibility back onto the user.
A common practice is to commit to an initial acknowledgement within a defined time window (for example within a few business days), then provide a separate expectation for follow-up. The acknowledgement can be automated, but it should be meaningful: confirm receipt, provide a reference number, and explain what information will be reviewed. This is especially helpful for organisations with multiple stakeholders where a report may need to move between marketing, web operations, and development.
The process after submission should be explained in plain terms. A useful pattern is: the report is reviewed, the issue is reproduced if possible, severity is assessed, and the user is updated with either a fix timeline or a workaround. Workarounds matter because some issues cannot be corrected instantly, yet users still need access. For example, if a checkout field is failing keyboard navigation, the organisation might provide an alternative order route or direct support while the fix is shipped.
Status updates should be intentional. If a fix will take time, a short update can maintain trust, even if the update is simply “the issue has been logged and is being worked on”. Where appropriate, the organisation can also share what has changed when the fix is deployed. This closes the loop and signals that user feedback leads to action. It can also help reduce repeat reports because users learn the organisation actively resolves accessibility barriers.
While users are waiting, offering practical resources can be helpful, as long as those resources are genuinely relevant and accessible. Links to help articles, alternative formats, or steps to complete a task in a different way can reduce immediate harm. This is most effective when it is framed as support, not as a diversion away from addressing the root issue.
Tracking recurring issues.
Accessibility improves fastest when reports are treated as operational data rather than isolated incidents. A structured issue log allows teams to identify recurring barriers, prioritise fixes, and measure progress over time. Without tracking, the same problems reappear across pages, especially when templates, reusable components, or third-party embeds are involved.
A workable tracking system does not need to be complex, but it does need consistency. Each report should be recorded with a date, page or component reference, category, severity, and owner. Resolution status should be visible so nothing disappears into an inbox. For product and growth teams, this log also becomes an input into conversion optimisation, because accessibility barriers often map directly to revenue leakage, such as abandoned forms, failed account creation, or unusable navigation on mobile devices.
Patterns should drive remediation. If multiple users report problems with the same UI component, the fix should happen at the component level, not as a one-off patch on a single page. This is particularly relevant for platforms that use repeated sections and blocks, where one change can remove barriers site-wide. When the organisation treats accessibility like quality assurance, recurring issues become signals for systemic improvement rather than ongoing firefighting.
Closing the feedback loop with users can turn a frustrating moment into a trust-building one. When a reported issue is resolved, a short follow-up message can confirm what changed and when. This acknowledgement reinforces that the organisation values the report and encourages continued engagement. It also helps users who rely on specific features to know when they can retry a task successfully.
Proactive audits complement user reports because not every user reports problems, and some users simply leave. Periodic checks, including manual keyboard testing and screen reader spot checks on critical flows, can uncover issues before they become widespread. For teams managing structured content and workflows, systems like Knack can be used to store accessibility tasks, link them to affected pages, and report on progress over time, creating a clearer operational view of accessibility debt and resolution velocity.
Accessibility becomes sustainable when insights are shared internally. Reports and patterns should feed back into design standards, content publishing checklists, and development conventions. Training sessions and short playbooks can prevent reintroducing the same errors, especially during redesigns, template changes, or marketing campaign launches. When accessibility is treated as a shared responsibility across operations, marketing, product, and development, the contact pathway becomes more than support. It becomes a learning loop that steadily improves the digital experience.
With a reliable reporting pathway and a disciplined tracking practice in place, the next step is to decide how accessibility work will be prioritised against other roadmap demands, and how improvements will be validated before they ship.
Play section audio
Updating statements over time.
Update when major redesigns happen.
When a website experiences a significant change, an accessibility statement needs to change with it. A major redesign rarely affects only visuals; it often reshapes templates, navigation patterns, interactive components, and the way content is structured in the page markup. Those shifts can create brand-new accessibility barriers, even when a site previously tested well. An up-to-date statement acts like a public status page for inclusion, showing what works, what still needs attention, and how the organisation is managing the gap between intent and reality.
Large changes commonly introduce risk in subtle places. A redesigned header can break keyboard navigation order. A new animation can ignore “prefers-reduced-motion” expectations. A refreshed product page can ship with missing form labels or confusing error messaging. Even a “simple” redesign that swaps out section layouts can alter heading hierarchy, landmark regions, and screen reader interpretation of the page. Because of that, teams benefit from treating a redesign as an accessibility reset point: reassess key user journeys, document new limitations, and then update the statement so it reflects the actual experience people will have that week, not the experience the site had last year.
It is also practical to gather feedback while the redesign is still in motion rather than after launch. Including people with disabilities in usability testing often surfaces issues that automated tooling will not catch, such as confusing focus states, unclear call-to-action language, or complex interactions that technically “work” but feel hard to use. Their feedback tends to be specific enough to translate into fixes and, where fixes cannot be completed immediately, into accurate disclosure in the statement.
After a redesign, teams often move quickly and ship improvements in batches. In that environment, it helps to document what changed and why. Notes like “navigation rebuilt with a new menu pattern” or “checkout form validation updated” can be linked to corresponding accessibility checks. That record supports future audits, reduces repeated investigations, and makes it easier to keep the statement aligned with the pace of product changes.
Maintain a “last updated” date for transparency.
A visible “last updated” date makes the statement credible because it helps visitors understand whether the information is current. Accessibility details can go stale faster than many teams expect, especially on sites that publish frequent content, run seasonal campaigns, or regularly adjust templates. A clear date signals that accessibility is treated as ongoing operations, not a one-time compliance exercise.
The date becomes even more valuable when paired with a short explanation of what triggered the update. For example, a statement might be refreshed due to a template refresh, a new booking flow, or remediation work after an audit. That context reassures users that updates are driven by real checks rather than superficial edits, and it gives internal teams a reliable reference point when questions come up about what changed and when.
Some organisations improve transparency by maintaining a lightweight version history. This does not need to become a legal document or a lengthy changelog. A short list of notable updates can be enough, such as “March 2025: navigation improvements and new keyboard focus styling” or “June 2025: updated form error messaging and alternative text guidance for new content uploads”. A concise history helps stakeholders track progress and prevents confusion when a user reports an issue that existed before a particular release.
Teams can also reduce maintenance overhead by using the platform’s workflow features. In a content management system, storing the statement as a standard page or entry allows quick edits, clear ownership, and review cycles. For Squarespace sites, that usually means keeping the statement in a dedicated page with controlled access, and pairing it with an internal checklist so updates do not rely on memory. What matters most is repeatability: updates should be easy enough that they actually happen.
Align statement with audits and remediation work.
An accessibility statement carries weight only when it matches what audits and fixes are discovering in practice. A structured WCAG audit identifies gaps across perceivable, operable, understandable, and robust content. When the audit results change the site, the statement should change too. This alignment is a form of accountability: it shows the organisation knows what is broken, knows what has been improved, and has a plan for what remains.
A useful pattern is to connect three things: what the audit found, what remediation has already shipped, and what is still being worked on. If an audit highlights missing form labels, the statement can acknowledge the issue, explain where it may appear, and note the remediation approach and timeline if one exists. If fixes have already been deployed, the statement can be revised to remove outdated limitations, preventing the site from underselling its improvements.
Automated testing tools are helpful, but they are not complete. They can flag missing alternative text or colour contrast failures, yet they often miss issues tied to real interaction, such as confusing focus traps in modals, unannounced content changes in dynamic UI, or poor error recovery in multi-step flows. Involving users with disabilities in audit validation strengthens the accuracy of remediation priorities, which then makes the public statement more honest and more valuable.
Audit alignment also supports internal decision-making. When teams can point to a statement that accurately reflects known limitations, it becomes easier to prioritise remediation in sprints, justify UI changes that improve accessibility, and prevent regressions in future releases. It turns accessibility into a managed system, not a collection of one-off fixes.
Avoid stale statements that damage credibility.
Outdated statements can do more harm than having no statement at all because they create a promise the site cannot keep. If a statement claims strong support for keyboard navigation or screen readers, but visitors experience broken focus order or unlabeled buttons, trust erodes quickly. Credibility matters here because accessibility is closely tied to dignity and independence. When the public information does not match reality, users may stop reporting issues or assume the organisation will not respond.
A maintenance routine prevents staleness. Many teams choose quarterly or twice-yearly reviews, with additional updates triggered by major releases, redesigns, or content model changes. This approach keeps the statement accurate without turning it into a weekly administrative burden. A well-run review includes quick checks of core journeys: navigation, search, forms, checkout or lead capture, and any gated user areas like account pages or portals.
Stakeholder variety improves the review quality. Designers may notice contrast and focus styling issues. Developers may spot semantic markup regressions or script-driven components that lost accessibility attributes. Content teams may catch heading misuse, link text problems, or missing alternative text patterns. Legal or operations teams can ensure the contact route for accessibility feedback still works and is monitored. The goal is not to create a large committee, but to ensure the statement reflects the lived reality across disciplines.
Usage insights can also help. When analytics show that visitors often land on the statement from mobile devices, it may hint that mobile accessibility concerns are common. When support logs show repeated accessibility-related questions, those issues should be reflected in the statement until they are resolved. This is not about tracking individuals; it is about spotting patterns that indicate friction and responding with clarity.
Keeping the statement fresh also makes it easier to handle public feedback. When the statement includes accurate known limitations and an active contact method, user reports become actionable rather than adversarial. That feedback loop improves both the site and the organisation’s relationship with its audience.
Use internal notes to track what drove each update.
Behind every public update there is usually a trigger: a release, an audit finding, a user complaint, or an internal discovery. Maintaining internal notes about those triggers helps teams avoid repeating work and supports better long-term decisions. These notes do not need to be public, but they should be accessible to the people responsible for maintaining the site.
Well-kept notes typically capture: what changed, why it changed, who approved it, and which pages or components were affected. Over time, this creates a practical history of accessibility work, allowing teams to spot recurring problem areas. If audits repeatedly highlight the same class of issue, such as inconsistent heading structure across templates or recurring button labelling problems in custom code, that pattern suggests the need for a more systematic fix rather than patch-by-patch remediation.
Operationally, teams can store these notes in a project tracker, a shared document, or a ticketing system that links to code changes and release notes. The benefit is continuity. When staff change roles, when agencies rotate, or when a business revisits a redesign months later, the organisation still retains the reasoning behind decisions and can defend or revise them intelligently.
A collaborative workflow also reduces risk. When accessibility updates are discussed in the same place where design and development work is tracked, accessibility stops being an afterthought. A small, consistent cadence works well, such as a monthly check-in where the team reviews new issues, confirms whether the statement needs a change, and validates that the public contact method is being monitored.
As organisations grow, it can be worth assigning clear ownership, whether that is a dedicated accessibility lead or a small task force with a defined responsibility. The goal is not bureaucracy; it is reliability. With ownership in place, the accessibility statement becomes a living artefact that stays aligned with audits, remediation, releases, and user feedback. That foundation sets up the next step naturally: deciding what a “good” update process looks like, and how to make accessibility reporting as routine as publishing any other critical site information.
Play section audio
Linking it appropriately.
Place it in the footer and policy hubs.
A public accessibility statement only helps when people can find it quickly, so the most dependable placement is the site footer. A footer link is visible from every page template, it stays in a predictable location, and it matches common web conventions people already understand. When someone is scanning for “serious” information before leaving a page, the footer is usually where they look for legal, trust, and support links, which makes it a practical home for accessibility.
It also pays to link the statement from existing policy clusters such as privacy, cookies, and terms. Many sites treat these pages as a “governance hub”, and users who open them are often looking for reassurance about how the organisation behaves. Adding the accessibility statement into that cluster frames accessibility as part of operational responsibility rather than a marketing claim. This is especially relevant for founders and SMB owners because it communicates maturity without adding friction to the primary conversion journeys.
Grouping links in the footer should be done with intent. If the footer contains dozens of items, the accessibility statement can get buried and become functionally invisible. A cleaner approach is to place it near other trust signals such as “Privacy”, “Terms”, “Contact”, and “Cookie settings”, and to keep the link text explicit. “Accessibility” or “Accessibility statement” is clearer than vague labels like “Help”. Clear labelling supports users who rely on screen readers and also reduces cognitive load for everyone else.
Visual cues can support discoverability, but they should never be the only cue. An icon can help sighted users recognise the link faster, yet the link must still be understandable as text, and the icon must have an accessible label in the underlying markup. In practice, that means prioritising descriptive link text first, then optionally pairing it with an icon if the design system already uses icons consistently across the footer.
For teams running Squarespace, the footer is also easier to maintain because changes propagate site-wide. That matters when policies evolve, templates get refreshed, or pages are added quickly during campaigns. A single, stable footer placement reduces the risk of the statement being forgotten on new landing pages, which is a common operational gap when marketing moves quickly.
Meet users where they ask for help.
Link from help and contact pages.
Help, support, and contact areas are high-intent moments where users are already signalling friction. Linking the accessibility statement from these pages reduces the distance between “something is difficult” and “here is how the organisation addresses accessibility barriers”. It also makes a practical promise: support is available, limitations are acknowledged, and there is a documented process for reporting issues.
Rather than dropping a bare link, a short sentence next to it can clarify why it exists and what it contains. For example, a single line that explains the page covers known limitations, assistive-technology compatibility, and how to request support can reduce uncertainty. This matters for users who are already stressed or time-poor, and it helps operational teams because it steers users towards self-service before they submit a ticket.
Support content is also a good place to point to alternative routes if a primary pathway is difficult. If the site includes live chat, email, a phone number, or a form, the help page can mention which option is best for accessibility-related issues. When that guidance links directly to the accessibility statement, it creates a “closed loop” where users can read the organisation’s commitments, then immediately act if something is not working.
FAQs and documentation can reinforce this without repeating the statement itself. A simple FAQ entry such as “How does the site support accessibility?” can briefly summarise key capabilities and then link to the full statement for detail. That keeps the main content from becoming bloated while still improving findability across multiple support surfaces.
Consistency in tone matters here. If the help page voice is friendly and practical but the statement reads like a legal disclaimer, users may feel the organisation is deflecting responsibility. Aligning phrasing and expectations across support pages and the statement helps the whole experience feel coherent, which in turn builds trust and reduces avoidable follow-up messages.
Ensure it is reachable on mobile.
Mobile navigation is not a “nice-to-have”. Many people, including users with disabilities, rely on mobile devices as their primary way to access services. The accessibility statement should be reachable from the mobile menu without requiring long scroll sessions or multi-step page journeys. If the link exists only in a desktop footer, it may be technically present but practically hidden on small screens.
Teams should confirm how the link appears in the mobile menu and in the mobile footer pattern used by the site. Some builds collapse the footer into accordions, hide it behind “More” menus, or place it after long lists of links. The goal is to keep the label easy to spot and the tap target easy to hit, especially for users with motor impairments or those navigating with assistive features such as switch control.
Regular testing should include real devices, not only responsive previews. Responsive previews can miss issues like sticky elements obscuring links, menu items that become untappable due to layering, or focus order problems when navigating with an external keyboard. When possible, feedback from users who actively use assistive technologies is more valuable than internal guesses because it reflects actual interaction patterns.
Placement inside the mobile menu should follow the same logic as desktop: group it with trust and support links, and keep the text explicit. If the menu uses shortened labels, “Accessibility” is usually the best compromise between clarity and space. Over time, this predictable placement helps users develop muscle memory, which improves speed and reduces frustration.
Keep the URL stable for referencing.
A stable page address makes the accessibility statement dependable for external linking and internal operations. When organisations, directories, procurement teams, or community resources reference a statement, they expect it to remain available. A changing link breaks that chain, and broken links can look like neglect even when the organisation is actively working on accessibility.
Choosing a clean, descriptive slug such as /accessibility-statement is usually the most understandable approach. It is predictable for humans, easier to remember, and aligns with how people search. Avoiding complex URL parameters also reduces the risk of duplicate URLs that confuse analytics and search engines, which can dilute visibility and make reporting harder for marketing and web teams.
If the site structure ever changes, redirects should be treated as part of change management rather than an afterthought. A proper redirect keeps old links working and preserves any earned search visibility. It also protects support teams, because old links often live in email templates, documentation, invoices, and onboarding sequences that can be difficult to fully audit after the fact.
Periodic link audits help catch failures early. Even a simple quarterly check to confirm the statement is reachable from key templates, the menu, and policy pages can prevent accidental regressions caused by redesigns, plugin changes, or CMS refactors.
Ensure it is indexed correctly.
Discoverability is partly a navigation issue and partly a search issue. Making sure the statement is included in the site’s sitemap and is not blocked by indexing settings improves the chance that people will find it via search, especially when they are evaluating a business quickly or comparing vendors. Search visibility also supports brand trust, because it shows the organisation is not hiding its accessibility commitments behind obscure navigation.
Structured data can also help search engines interpret what the page represents. When teams use schema thoughtfully, it provides clearer signals about the page topic and intent. The aim is not to “game” rankings, but to reduce ambiguity so the right page appears for the right query. Any implementation should be validated to avoid markup errors that can confuse crawlers and reduce overall site quality signals.
Ongoing monitoring matters because indexing is not a one-off task. Tools such as Google Search Console can indicate whether the page is indexed, whether it is being excluded, or whether crawl issues exist. If the page is missing from the index, the root cause is often simple: the page is set to noindex, it is orphaned, it is blocked by robots rules, or it is buried behind unusual navigation patterns.
Keeping the statement current also supports indexing indirectly. Search engines generally favour content that stays relevant, and users are more likely to trust a statement that reflects the site as it exists today. When teams update site features, templates, or key flows, the statement should be reviewed so it remains accurate and useful.
Once the accessibility statement is easy to reach, stable to reference, and discoverable through search, it starts doing its real job: reducing uncertainty and friction for users who need support. From there, the next step is making sure the statement content itself is specific, testable, and aligned with how the site actually behaves.
Play section audio
Testing discipline.
Define a simple checklist.
A practical accessibility testing discipline often starts with a lightweight accessibility checklist that can be repeated on every release, not a long document that nobody finishes. The aim is to standardise what gets checked, when it gets checked, and how issues get recorded, so accessibility stops being “something to remember” and becomes routine. For founders and small teams, this approach also prevents late-stage surprises where a launch gets delayed because key UI elements cannot be used without a mouse.
The checklist works best when it focuses on high-impact risks that frequently break in real builds: keyboard access, focus order, colour contrast, heading structure, and form labelling. These areas map directly to the way assistive technologies behave. When keyboard navigation fails, users who rely on a keyboard, switch device, or voice control can get stuck. When focus order is chaotic, users can lose context and miss content. When contrast is weak, many users struggle, including people with low vision, colour blindness, migraines, or users viewing a screen in bright sunlight.
Keeping the checklist short does not mean keeping it vague. Each item should be testable and tied to a pass/fail outcome. For example, “keyboard navigation works” is hard to measure, while “all interactive elements can be reached with Tab, activated with Enter/Space, and escaped from with Escape where relevant” is measurable. Teams building on Squarespace can still run this discipline, even when templates limit deep structural changes, because the checklist is about behaviour and outcomes, not about full control of the underlying markup.
As the site evolves, the checklist should evolve too. The discipline is maintained by revisiting the checklist when new components are added, when design systems change, or when a new integration is introduced, such as a booking widget, embedded checkout, or third-party form. Accessibility regressions commonly arrive through these “small additions”, especially when scripts inject new buttons, modals, or dynamic content that is not correctly labelled or focus-managed.
Checklist items.
Keyboard navigation
Focus management
Contrast ratios
Heading structures
Form accessibility
Test core journeys.
Once the checklist exists, accessibility testing becomes more effective when it targets core user journeys, not isolated pages. A website can pass a quick homepage review while still failing at the point where revenue or leads are created. For service businesses, this is often a contact or booking flow. For e-commerce, it is add-to-basket, basket editing, checkout, and post-purchase confirmation. For SaaS, it is the trial funnel, pricing selection, and account creation.
Journey testing means stepping through the entire process using realistic constraints. Keyboard-only navigation is one constraint, and it should be treated as a first-class way to use the site. Another constraint is zoom and reflow: at 200 percent zoom, layouts often collapse in ways that hide buttons, trap content, or cause menus to overlap. A third constraint is error handling: forms that look fine when completed correctly often fail when a user makes a mistake, because the error message is not announced to assistive technology or does not explain how to fix the issue.
Device and browser variability matters because accessibility can degrade at the edges. An animation-heavy menu may behave differently in Safari compared to Chromium-based browsers. Some embedded booking tools are usable on desktop but become frustrating on mobile when focus jumps unexpectedly. When teams build quickly, it is common to test a journey in one browser on one device and assume everything else is fine. A disciplined approach deliberately samples the combinations most users actually have: mobile Safari, desktop Chrome, and at least one alternative browser for cross-checking.
Where possible, real-user testing provides insight that automated scans will not detect. Automated checks can flag missing labels and low contrast, but they cannot reliably judge whether the wording of instructions is understandable, whether a checkout flow feels predictable, or whether the tab order matches the visual order. Even a small, time-boxed test session with a participant who uses assistive technology can uncover “invisible blockers” such as confusing focus behaviour, missing context on buttons (“Click here”), or headings that visually look fine but are structurally incorrect.
Documenting the outcome of each journey test helps teams avoid repeating the same mistakes. The record should note what was tested, which device/browser was used, what failed, and the severity. Severity can be practical rather than theoretical: “prevents checkout completion”, “prevents submitting booking request”, or “causes confusion but workarounds exist”. This makes it easier for ops, marketing, product, and dev teams to agree on priorities without debating abstract compliance language.
Core journeys to test.
Navigation
Contact forms
Checkout or booking processes
Test with screen reader basics.
Keyboard testing catches a lot, yet it does not fully represent the experience of users who depend on a screen reader. Screen readers translate page structure into spoken output or braille, so the “hidden layer” of headings, labels, landmarks, and alternative text becomes the primary interface. This is where sites often fail, especially when visuals are prioritised and semantics are treated as optional.
Basic screen reader testing does not need to be intimidating. The goal is not to become an expert user of assistive technology; it is to validate that essential information is announced, the structure makes sense, and interactive elements can be operated without guesswork. A good baseline is checking that headings communicate a meaningful outline, that links and buttons have descriptive names, and that form inputs have labels that are read aloud in a helpful way.
Images deserve specific attention. Decorative visuals should not create noise, while meaningful visuals should have text alternatives that match their purpose. A product image might need a short descriptive label; an icon-only button needs an accessible name that explains its action. A common failure pattern is a button that looks like a magnifying glass, a hamburger menu, or a close icon, but is announced to the screen reader as “button” without context. That forces users to explore by trial and error, which slows them down and creates unnecessary friction.
Structure and navigation are equally important. If headings are skipped or used purely for styling, screen reader users lose the ability to jump quickly to the section they want. If a modal opens and focus does not move into it, users can end up “behind” the modal, still tabbing through the page they can no longer see. If a modal closes and focus is not restored, users may be forced to restart navigation from the top. These are not edge cases; they happen frequently in real-world builds that use pop-ups, quick-view product panels, and cookie banners.
Teams can keep this manageable by selecting a few representative pages and repeating the same quick routine on each: read the page title, traverse headings, tab through interactive controls, attempt a form submission, and confirm that errors or success messages are announced. This routine becomes even more valuable when new components are introduced, because dynamic UI is where regressions most often appear.
Screen reader testing tips.
Use popular screen readers such as NVDA or VoiceOver
Check for missing alternative text
Confirm heading hierarchy and meaningful labels
Test form completion, including error messages
Track issues and fixes.
Accessibility improvements rarely stick unless they are tracked with the same seriousness as performance bugs or conversion blockers. A lightweight issue tracker creates continuity, especially when multiple people touch the site, such as a marketer updating pages, an ops lead managing forms, and a developer handling integrations. The point is not bureaucracy; it is preventing the same problems from resurfacing every quarter.
Good tracking starts with consistent fields: where the problem occurs, what a user was trying to do, what actually happened, and how to reproduce it. Including reproduction steps matters because accessibility bugs can be sensitive to context, such as a specific template, a specific browser, or a specific embedded widget. When teams skip these details, issues can get marked “fixed” without actually being fixed, simply because the person retesting did not recreate the original conditions.
Prioritisation should map to user impact. A contrast issue on a low-traffic blog page might be medium priority, while a focus trap in checkout is critical. This impact-based approach aligns accessibility with business outcomes in a way that founders and SMB owners can act on: fewer abandoned baskets, more completed bookings, and fewer support requests caused by confusing forms.
Patterns are a key output of tracking. When a team reviews its accessibility log, recurring issues tend to reveal root causes: a design pattern that produces low contrast, a reusable component that lacks proper labelling, or an embedded script that breaks focus order. Fixing the root cause is usually cheaper than repeatedly patching individual pages. For teams using no-code and low-code tools, this often means standardising blocks, reusing proven sections, and avoiding custom scripts that introduce interactive elements without accessibility support.
Sharing fixes internally also improves speed over time. A short internal note explaining what was wrong, why it mattered, and what resolved it helps non-technical contributors make better choices later. It is especially useful for content teams, because many accessibility issues are content-driven: unclear link text, poor heading structure, missing captions, and inconsistent form instructions.
Tracking methods.
Document issues and resolutions with reproducible steps
Monitor recurring problems to find root causes
Allocate resources based on user impact and business risk
Treat accessibility as part of QA.
When accessibility is handled only at the end of a project, it often becomes expensive, stressful, and incomplete. Mature teams treat it as a normal part of quality assurance (QA), checked alongside layout, copy, analytics events, and performance. This shift matters because accessibility issues are often created by everyday actions: a new pop-up, a new page section, a new button style, or a new third-party embed.
Embedding accessibility into QA means defining “done” in a way that includes accessible behaviour. A feature is not complete if it works only with a mouse. A form is not complete if errors are not understandable and discoverable. A navigation change is not complete if the tab order becomes unpredictable. Once these expectations are written into the team’s QA routine, accessibility becomes predictable, and releases stop creating accidental blockers.
Training is part of the system. QA testers do not need to memorise every guideline, yet they do need repeatable heuristics: checking that interactive elements have visible focus, ensuring headings follow a logical order, verifying that labels match inputs, and confirming that colour is not the only way information is conveyed. A short internal reference page or a shared checklist can standardise these checks across team members, including contractors.
Regular audits help keep the standard steady, especially for websites that change frequently. An audit can be as small as a monthly spot-check of high-traffic pages and core journeys, plus a deeper quarterly review. The discipline pays off because regressions are caught while they are still small. For organisations that publish frequently, this approach also supports content operations, because accessibility becomes part of the publishing workflow rather than a retroactive fix.
As this discipline becomes routine, teams often find it easier to align accessibility with broader goals: improved usability, stronger SEO through clearer structure, better conversion rates through clearer forms, and fewer support requests caused by confusion. The next step is translating the testing discipline into a repeatable workflow that fits the tools the business already uses, from no-code publishing to developer-led releases.
Play section audio
Why accessibility statements matter.
Show users accessibility is taken seriously.
Publishing an accessibility statement signals that inclusivity is part of the organisation’s operating standard, not an afterthought. It sets expectations about how the site is intended to work for people with disabilities, and it frames accessibility as a quality attribute just like performance, security, or reliability. When visitors see this transparency, they are more likely to explore content, attempt a purchase, submit a form, or contact support, because they can trust that barriers are recognised and being addressed.
It also supports brand credibility in practical ways. Teams often invest heavily in design polish and conversion optimisation, yet overlook how easily a visitor can navigate without a mouse, interpret the interface with a screen reader, or complete key flows when motion, contrast, or timing creates friction. A clear statement helps close that gap by communicating intent and ownership. For founders and SMB operators, this matters because trust compounds: a user who feels accommodated is more likely to return, recommend the service, and stick through product changes.
For organisations operating globally, accessibility also intersects with reputation management. Social platforms and review sites make it easy for users to share negative experiences when a site blocks them. A statement cannot fix an inaccessible interface, but it does show that the organisation is listening and has a route for addressing issues, which often changes the tone from frustration to collaboration.
Building trust through transparency.
Trust improves when the organisation explains what it has done, what still needs work, and how users can report problems. That is where transparency becomes a usability tool. When someone relies on assistive technology, uncertainty is expensive: they might abandon the process if they suspect the checkout will fail, or if a form is likely to trap keyboard focus. A transparent statement reduces that uncertainty by clarifying known limitations and supported pathways.
Transparency also creates a feedback loop that can improve the product. If the statement includes a clear contact method and response expectations, users can report real-world issues that automated tests miss. For example, an automated scan might flag missing alternative text, but only a user can explain that the alternative text is unhelpful, repetitive, or misleading in context. When teams treat that input as product feedback rather than support noise, accessibility work becomes part of continuous improvement.
It can also strengthen internal accountability. When a public document names the standards the organisation aims to meet and the channels it uses to resolve issues, it becomes harder for accessibility work to be deprioritised indefinitely. It moves accessibility from “someone should fix that” to “the organisation has committed to this”.
Explain how accessible the content is.
An accessibility statement is also a practical resource. It should describe which parts of the experience are accessible, which tools are supported, and what users can do when a barrier appears. For teams shipping content weekly, this is especially important because accessibility problems often come from content operations rather than the template itself. A page can be built on a clean layout, then become inaccessible due to heading misuse, poorly labelled links, missing captions, or a PDF that cannot be navigated with a screen reader.
Clear information helps users choose the path of least resistance. If a site supports keyboard navigation but certain embedded widgets do not, the statement can disclose that and offer a workaround, such as a plain HTML alternative, an email route, or an accessible download. This is not about lowering expectations; it is about reducing wasted time for users who already face more friction than most visitors.
This approach also benefits analytics and conversion. When the statement points users to accessible alternatives, the organisation reduces abandonment and increases task completion. A lead who cannot use a scheduling widget might still book a consultation if the statement points them to an accessible form or a direct email option.
Highlighting accessibility features.
Strong statements translate accessibility work into concrete features that people can use. That usually means listing what has been implemented and how it behaves. Examples that commonly belong here include keyboard navigation support, visible focus states, semantic headings, text alternatives for meaningful images, form labels, and compatibility with screen readers. Where relevant, it helps to mention media support, such as captions for video and transcripts for audio.
Practical guidance should accompany the list, because features only help when users know they exist. A statement might explain that the site can be navigated using the Tab key, that menus can be opened via Enter, or that users can zoom up to 200% without breaking layout. For some audiences, it can also clarify that the site does not rely on colour alone to convey meaning, which is crucial for visitors with colour vision deficiencies.
When the platform is Squarespace, it is often useful to be explicit about the split between template-level accessibility and content-level responsibility. A template may provide accessible foundations, but day-to-day publishing practices decide whether a specific page remains accessible. Mentioning that the organisation trains content editors on headings, link text, and image descriptions demonstrates operational maturity.
Edge cases are worth acknowledging without over-promising. Examples include third-party booking tools, embedded maps, payment widgets, or chat plugins that may not fully meet the same accessibility standard as the rest of the site. Stating this honestly, along with an alternative way to complete the task, often prevents users from getting stuck at the most critical moment.
Show social responsibility and intent.
Accessibility is often discussed as compliance, but it is more accurately a commitment to equitable participation. A public statement anchors that commitment. It communicates that people with disabilities are not treated as edge cases, and that the organisation intends to remove barriers rather than tolerate them. For service businesses, SaaS products, and e-commerce brands, this matters because the website is not a brochure; it is the front door, the sales channel, and the support desk.
Social responsibility in accessibility is also about designing for real-world constraints. People browse on older devices, in bright sunlight, with temporary injuries, or under cognitive load. Improvements like clear focus indicators, readable typography, and predictable navigation patterns often help everyone. A statement that frames accessibility as universal usability makes the work feel relevant to the whole customer base, not just a subset of visitors.
For leadership teams, documenting intent can also guide vendor decisions. When the organisation states its accessibility goals publicly, it becomes easier to evaluate external tools and plugins through that lens. If a new marketing pop-up tool cannot be operated by keyboard, it becomes an obvious mismatch rather than a “nice to have” feature that quietly damages usability.
Aligning with legal obligations.
Regulatory expectations are moving fast, and teams operating in Europe should keep an eye on the European Accessibility Act. A good statement cannot replace compliant design and development, but it can support a defensible posture: it shows awareness, outlines standards, and demonstrates that the organisation is actively working through gaps. That matters for risk management, partnerships, and procurement, especially when clients ask about accessibility readiness during due diligence.
A statement should avoid vague claims such as “fully accessible” unless the organisation can substantiate it. A more credible approach is to name the standard targeted, describe the testing approach, and clarify what is still in progress. If audits are performed, the statement can mention the cadence, such as quarterly reviews, without inventing results or overstating coverage.
As legislation changes, the statement should be revisited so it remains aligned with current obligations and best practices. A dated statement can create unnecessary exposure, because it signals neglect. Keeping it current signals operational discipline.
Reduce legal risk by documenting action.
An accessibility statement can function as evidence of good-faith effort. By outlining what has been done and what is planned, the organisation creates a record that can reduce legal exposure. That does not mean using the statement as a shield; it means treating accessibility as a managed programme rather than an ad hoc set of fixes.
If a user hits a barrier, the presence of a clear escalation path can prevent a negative experience from becoming a complaint. When users can report issues easily and receive a timely response, they are more likely to stay engaged. They are also more likely to choose the organisation again, because they have seen responsiveness in action.
This is especially relevant for small teams where support bandwidth is limited. A well-structured statement can reduce repeated queries by setting expectations and by pointing to known workarounds. It can also route issues to the right internal owner, whether that is the web lead, operations, or a developer managing the stack.
Documenting the journey.
A useful way to strengthen the statement is to include a lightweight timeline of key milestones, such as when an accessibility review was performed, when major navigation changes were made, or when video captions became standard practice. The point is not to publish internal notes; it is to show that the organisation improves the experience over time.
Where appropriate, teams can explain the process they follow when issues are reported. For example: acknowledge receipt, assess severity, provide a workaround, then schedule a fix. That kind of process detail reassures users that the organisation will not ignore them, and it helps set realistic expectations about resolution time.
If the organisation has learned from past issues, it can describe what changed. A common example is moving from image-only buttons to properly labelled controls, or replacing vague links like “click here” with descriptive link text. These examples keep the statement grounded in real actions rather than abstract promises.
Keep a living record of progress.
An accessibility statement should not be treated like a one-time page that gets published and forgotten. It works best as a living document tied to the site’s release rhythm. As new pages, new integrations, and new campaigns go live, the accessibility surface area changes. Keeping the statement updated shows that the organisation understands this reality and is actively managing it.
Maintaining an ongoing record also helps prioritisation. Teams can track recurring issues, identify which content types generate the most accessibility problems, and improve publishing workflows accordingly. For example, if most problems come from blog images lacking meaningful descriptions, the fix is not only technical; it is operational, involving editorial checklists and training.
This also fits evidence-based decision-making. When accessibility issues are logged and categorised, the organisation can connect them to business impact such as drop-offs in forms, support requests, or poor engagement on certain pages. Accessibility then becomes part of performance optimisation, not a separate category of work.
Setting measurable goals.
Measurable goals turn accessibility from intention into execution. Goals might include a deadline for remediating known issues, a commitment to caption all new video content, or a requirement that every form field has a label and error messaging that can be understood by assistive technologies. When goals are concrete, teams can plan resourcing, validate progress, and communicate updates without vague language.
Input from users with disabilities is particularly valuable here because it highlights friction that checklists often miss. Structured feedback sessions, usability testing, or even a simple “report accessibility issue” form can reveal problems such as confusing focus order, unclear link context, or content that relies too heavily on visual cues. The statement can invite this feedback and explain how it is handled.
When the site relies on no-code and low-code tooling such as Squarespace, content governance becomes part of accessibility governance. Establishing publishing rules for headings, alternative text, link labels, and embedded media reduces regression risk as the team scales content output. For organisations with more complex stacks, the same principle applies via design systems, component libraries, and automated checks in deployment pipelines.
From here, the next step is turning the statement into a repeatable workflow: define ownership, set a review cadence, and align the document with the site’s actual behaviour across devices and assistive technologies.
Play section audio
Legal requirements and compliance.
Adhere to WCAG requirements.
Meeting the Web Content Accessibility Guidelines (WCAG) is widely treated as the baseline for making a website usable for people with disabilities and, just as importantly, for reducing compliance risk. WCAG is not a design trend or a “nice to have”; it is a technical standard describing how digital content should behave so it can be perceived, operated, and understood by users who rely on assistive technologies or alternative interaction methods. When organisations align with WCAG, they typically see fewer usability dead ends, clearer journeys, and more consistent site behaviour across devices.
From a legal perspective, WCAG is often the practical yardstick referenced by regulators and courts when evaluating digital accessibility. In Europe, accessibility obligations show up in instruments such as the EU Web Accessibility Directive for public sector bodies, with wider market coverage becoming increasingly relevant as the European Accessibility Act applies to more digital services, including areas that affect e-commerce. In the United States, the Americans with Disabilities Act (ADA) continues to influence expectations around access to digital services, even though it is not written as a web standard. The operational reality is simple: when a site fails basic accessibility checks, legal exposure rises, complaint handling becomes reactive, and internal teams lose time in fire-fighting mode.
Many organisations aim for WCAG 2.2 Level AA because it is demanding enough to materially improve access while still being achievable for most websites. AA often captures the issues that actually block people: keyboard traps, missing labels, poor focus visibility, and content that collapses when text size changes. A concrete example is text resizing: if content must scale to 200% without breaking layout or hiding actions, then page templates need to be responsive in a genuinely robust way, not only “mobile friendly” in a marketing sense. Another practical example is keyboard access: if every function cannot be completed without a mouse, then users who navigate by keyboard, switch devices, or voice control may be locked out of checkout, forms, or account screens.
Accessibility compliance also behaves more like security than like branding. It cannot be “done once” and left alone because websites change constantly: new pages, new scripts, new pop-ups, new product blocks, new embedded tools. Each change can introduce regressions such as a modal that steals focus, a carousel that cannot be paused, or a form error that is only shown in red text with no programmatic announcement for screen readers. Maintaining compliance requires an ongoing process where teams treat accessibility as part of routine quality assurance, not as a one-off project at the end.
There is also a business and ethical angle that tends to be undervalued. Accessibility is a form of operational respect: it acknowledges that people interact with the web in varied ways, and that a brand’s “digital reality” should match its promises. When a service business, SaaS product, or e-commerce shop is accessible, it usually becomes easier for everyone to use: clearer navigation, better content structure, fewer confusing interactions. These improvements often support SEO and conversion too, because search engines and users both benefit from predictable structure, meaningful headings, and descriptive links.
Key WCAG principles.
Perceivable: content must be presented in ways users can sense. Typical implementations include descriptive alt text for images, captions and transcripts for video, and layouts that still make sense when styles are overridden or text is enlarged. For example, a product image should not have alt text like “image”; it should describe what matters, such as the product name or differentiating feature when the image carries meaning.
Operable: interactions must work across different input methods. This includes complete keyboard access, visible focus states, avoiding keyboard traps, and ensuring that time limits do not silently block completion. For example, a checkout timer that expires without warning can be inaccessible, while a timer with clear notices and a simple extension option is easier to operate.
Understandable: users must be able to comprehend both content and behaviour. This is where plain language, predictable navigation, consistent components, and helpful error handling matter. For example, when a form fails, the page should identify which field failed, why it failed, and how to fix it, rather than showing a generic “something went wrong”.
Robust: content must work reliably with different browsers and assistive technologies. This usually comes down to semantic HTML, valid structure, and careful use of ARIA. When developers rely on standard patterns, a screen reader is more likely to interpret components correctly today and in future updates.
Include standards and evaluation methods.
An accessibility statement is not just a legal box to tick; it is a technical disclosure that explains how seriously accessibility is handled and what “accessible” means in the organisation’s context. A strong statement names the target standard explicitly, such as WCAG 2.2 Level AA, and avoids vague promises like “strives to be accessible”. Stating the standard matters because it sets an objective benchmark for internal teams, vendors, and users who need to understand what level of support they can expect.
The statement also benefits from explaining how compliance is evaluated. A site that has only run an automated scan is in a different position from a site that has been manually tested with a keyboard, checked with screen readers, and reviewed against common interaction patterns such as menus, modals, filters, and checkout steps. Mentioning whether the review was a self-assessment or a third-party audit builds trust. Including the date of the last evaluation signals that accessibility is active work rather than a forgotten policy page.
Transparency tends to work best when it is specific. If a site is partially compliant, the statement can name known limitations without undermining confidence. For instance, it might acknowledge that an embedded third-party widget is being replaced, or that certain legacy PDF documents are being remediated on a schedule. This is particularly important for founders and SMB teams who often rely on external booking engines, payment widgets, or CRM embeds. Those tools can introduce accessibility risks, so the statement should clarify what is controlled internally versus what is dependent on third parties.
Where it makes sense, an improvement roadmap can be outlined in broad strokes. It does not need to be a public project plan; it can be a simple set of priorities such as “improving keyboard navigation in the main menu”, “adding captions to the video library”, or “upgrading form validation messaging”. This helps users understand that issues are not being ignored, and it helps internal stakeholders align effort across content, design, and development.
Evaluation methods.
Most effective programmes use a mix of automated scanning and human testing because each method finds different classes of problems. Automated tools can quickly catch missing alt attributes, colour contrast warnings, missing form labels, heading order issues, and some ARIA misuse. Manual testing is needed to verify real interaction quality, such as whether a modal traps focus, whether a dropdown works with arrow keys, or whether error messages are announced correctly by a screen reader.
A practical evaluation workflow often includes: automated scans on key templates, keyboard-only walkthroughs of primary journeys (contact forms, checkout, login, search), and spot checks with screen readers on representative pages. For teams shipping frequently, accessibility checks can be added to release gates, similar to performance budgets or SEO checks. This reduces regressions that accumulate quietly over time.
Where possible, involving people with disabilities in usability testing provides insight that tools and internal teams can miss. A developer may confirm that a component “technically works”, while a real user may reveal that the flow is exhausting, confusing, or inconsistent. This feedback is especially valuable on high-friction areas like onboarding, account management, pricing tables, and multi-step forms.
Keep the statement updated.
An accessibility statement becomes unreliable when it is not maintained. If a website is redesigned, a new theme is deployed, a cookie banner changes, or new product pages roll out, the statement should reflect that the site has been re-evaluated. Many teams schedule a review at least annually, but higher-change environments, such as e-commerce shops with frequent campaign landing pages or SaaS sites with constant UI experiments, usually need more frequent reviews.
Updates should include the date of the last review and a short note about what changed, such as “navigation updated and re-tested for keyboard access” or “video captions added across the help centre”. This creates accountability and provides evidence of ongoing work if questions arise later. It also helps internal operations by leaving a trail of decisions: what was fixed, what remains, and why.
Refreshing the statement can also improve support efficiency. When the statement clearly explains known limitations and the best way to get help, fewer users end up stuck in generic support loops. For a lean team, that means fewer ambiguous tickets and quicker triage, because accessibility feedback arrives with context and can be routed to the right owner.
Updating process.
Run scheduled accessibility checks across core templates and high-traffic journeys.
Record changes, regressions, and fixes in a simple log tied to release notes.
Revise the accessibility statement to reflect the current status, evaluation date, and any known issues.
Publish the update and, where appropriate, communicate changes in a changelog, footer notice, or support page.
Make new features accessible by design.
Accessibility is easiest and least expensive when it is built into the workflow rather than bolted on after launch. When new features are added, whether that is a booking form, a pricing toggle, a product filter, or a gated download, they should be reviewed against the same standard used for the rest of the site. This protects users from sudden dead ends and protects the organisation from introducing compliance gaps with every release.
Operationally, this means training both developers and content creators. Many accessibility failures are not “complex engineering problems”; they are content and structure issues: headings used for styling instead of hierarchy, link text like “click here”, images with missing or misleading alt text, or PDFs uploaded without any tagging. On platforms like Squarespace, where teams often move fast with templates and blocks, governance matters because one small styling decision can affect a whole collection page or repeated block pattern.
Engineering teams benefit from a definition of done that includes accessibility checks. For example, when shipping a new interactive element, the acceptance criteria can require: full keyboard operation, visible focus, sensible tab order, sufficient colour contrast, and screen reader labels for controls. This is also where “edge cases” matter. A component may work with a short label but fail when labels wrap onto multiple lines, when the page is zoomed to 200%, or when the interface is viewed on a small screen with large text settings. Testing those conditions early prevents expensive rework later.
Teams that use automation platforms such as Make.com or embed external tools should also account for accessibility impact. A third-party widget can introduce inaccessible markup, unexpected focus behaviour, or non-compliant colour contrast. In those cases, the organisation may not be able to fix the widget directly, but it can often mitigate risk by providing an accessible alternative path, adding clear instructions, or choosing vendors with published accessibility conformance reports.
Implementation strategies.
Provide accessibility training for anyone publishing content or building features, covering semantics, forms, media, and interaction patterns.
Use automated testing during development to catch common failures early, then validate critical journeys with manual keyboard and screen reader checks.
Run usability testing with people who use assistive technologies, especially for revenue-critical flows like enquiry capture, checkout, and account management.
Offer a clear way to report issues.
An accessibility statement should never be a dead end. It needs clear contact routes so users can report barriers, request alternative formats, or ask for help completing a task. This feedback loop is one of the fastest ways to uncover issues that slipped through testing, such as a broken focus state after a script update or an inaccessible PDF that was uploaded by a well-meaning team member.
Contact options work best when they match different communication needs. Email is common, but it should not be the only path. Some users may prefer a form, some may require text-based support, and some may need a phone option with appropriate accommodations. Whatever channels are offered, they need to be accessible themselves, including labels, validation messaging, and confirmation states.
Responsiveness is part of compliance culture. If a business asks users to report issues but does not reply promptly, trust erodes and complaints escalate. Clear response-time expectations make the process feel real, and they help internal teams triage. It also helps to publish a short set of details users can include in a report, such as the page URL, device type, browser, and what they were trying to do. That reduces back-and-forth and speeds up fixes.
For organisations managing multiple sites or high volumes of support, tools that reduce repetitive queries can complement accessibility reporting. For example, an on-site assistant such as CORE can deflect common “how do I” questions and free capacity so the team can focus on genuine accessibility barriers when they are reported.
Contact information best practices.
Publish a dedicated email address for accessibility support and keep it easy to locate from the footer and the accessibility statement.
Offer an accessible contact method for users with hearing impairments, such as text-based support, and ensure staff know how to handle those requests.
Provide a simple contact form with proper labels, logical tab order, and clear error messages that work with assistive technologies.
State response-time expectations and follow through with consistent triage, tracking, and resolution updates.
Once legal grounding, evaluation, and feedback channels are in place, the next step is turning compliance work into practical, ongoing operations so accessibility improvements continue even as content, campaigns, and features evolve.
Play section audio
Best practices for accessibility statements.
Use plain, direct language.
An effective accessibility statement works like a public promise and a practical help page at the same time. That only succeeds when the wording is easy to understand for people with different levels of technical confidence, different cognitive loads, and different assistive technologies. Clear language reduces the chance that someone gives up at the exact moment they need support, such as when a form will not submit, a menu cannot be used on a keyboard, or a document will not open on mobile.
Clarity also means describing issues in human terms, not compliance shorthand. Saying “WCAG Success Criterion 1.2.2 was not met” might be accurate, but it does not help someone who simply needs to know why a video is hard to follow. A more useful phrasing is “some videos do not have captions yet”, followed by what alternatives exist (a transcript, a summary, or a contact route). This keeps the statement informative without forcing visitors to interpret standards language.
Plain language does not mean removing all technical detail. It means leading with outcomes and then layering depth when it helps. A good pattern is: problem, impact, workaround, fix timeline. For example, “Some carousel controls are not fully usable with a keyboard (impact). Users can navigate the same content using the links below the carousel (workaround). A fix is scheduled for the next release cycle (timeline).” This style respects time and reduces frustration.
Key tips for language clarity:
Minimise jargon, and when a term is necessary, define it in the same sentence.
Prefer active voice and concrete subjects (“the team is updating…”, “the site supports…”).
Keep paragraphs short and focused on a single idea, especially for mobile reading.
Format the statement for scanning.
Most people do not read an accessibility policy from top to bottom. They scan it when something goes wrong, often while using a screen reader, voice control, switch access, or a mobile device with zoom enabled. A statement with clear headings and predictable structure helps those visitors find answers quickly and lowers support load because fewer people need to ask the same question repeatedly.
Structure is not just visual. It is also semantic. When headings are used in the right order, assistive tech users can jump between sections efficiently. A tight structure also helps internal teams maintain the statement over time, because each block has a clear purpose and can be updated without rewriting everything else. In operational terms, a well-structured statement becomes part of content governance, not an “extra page that nobody owns”.
Longer statements can benefit from a simple contents list near the top, particularly when the organisation operates multiple services, has several known limitations, or supports multiple platforms (such as Squarespace for marketing pages and a separate web app for logged-in users). Even without a formal table of contents, consistent subheadings like “Standards”, “Known issues”, “Contact”, and “Update schedule” make the page predictable, which is a usability win.
Formatting best practices:
Use bullet points for limitations and workarounds so they are easy to skim.
Keep typography consistent and avoid dense blocks of text that require sustained focus.
Order information by urgency: what works, what does not, what to do if stuck.
Be transparent about standards and gaps.
Trust is built when the statement clearly explains which guidelines the organisation is aiming to meet and what “good” looks like for that site or product. Many organisations reference WCAG because it offers a shared language for accessibility outcomes. Naming the target level (A, AA, or AAA) sets expectations and gives internal teams a measurable benchmark for audits and roadmaps.
Honesty matters most when discussing limitations. Visitors typically do not expect perfection, but they do expect clarity. If a site has known issues, the statement should say so plainly and describe what the organisation is doing about it. This is especially important when barriers affect high-intent actions, such as checkout, booking, account access, or contact. A vague statement like “we are always improving” does not help someone who needs to complete a task today.
Limitations should be specific enough to be actionable, without turning the statement into a bug tracker. A practical middle ground is listing the affected component, the impact, and a workaround. For example: “PDF brochures may not be fully tagged for screen readers. The same information is available on the web pages under Services. If a document is needed in an alternative format, contact support.” This approach reduces friction while signalling that the issue is recognised and being addressed.
Consider including:
The current target and status against WCAG (including the level aimed for).
A short list of known barriers, each paired with a workaround or alternative path.
Any assistive technology notes that are genuinely tested, such as screen reader and browser combinations, when available.
State improvement goals with timelines.
Accessibility is a moving target because websites change, content grows, third-party tools update, and standards evolve. A strong statement reflects that reality by outlining what the organisation plans to improve and when. These goals should connect directly to the limitations listed earlier, so the page reads as a coherent plan rather than a collection of unrelated promises.
Goals become more credible when they are framed as outcomes and milestones. “Improve keyboard navigation” is a start, but “ensure all main navigation items can be reached and activated using keyboard-only input” explains what success means. Where possible, include a timeframe that matches the organisation’s release cadence, such as “in the next quarter” or “during the next redesign cycle”. If a firm date cannot be promised, it is still useful to explain what triggers the fix, such as “scheduled when the video library is refreshed”.
Practical examples help users understand what is being improved. Adding captions to key videos, improving focus states, fixing form error messaging, and ensuring colour contrast for call-to-action buttons are all common priorities. It also helps to describe how improvements are validated, such as audits, regression checks after releases, and user testing with people who rely on assistive tech.
Future goals might include:
Delivering specific upgrades within a defined cycle, such as captioning priority videos or improving form labels.
Scheduling recurring accessibility checks, particularly after design refreshes or feature launches.
Including people with disabilities in feedback and testing so real-world barriers are found earlier.
Make it easy to find on-site.
A statement that cannot be found cannot help anyone. The link should sit where users expect to find it when they are stuck, such as the footer, help area, or contact section. Organisations that run multiple sites or subdomains can reduce confusion by using a consistent label across properties, so visitors do not need to guess whether it is called “Accessibility”, “Accessibility help”, or “Inclusive design”.
Placement also supports operational resilience. When the statement is accessible from every page, support teams can send a single link that always works, and users can find it without searching. This is particularly helpful for sites built on templates where navigation may differ slightly across page types. It also supports SEO and discoverability for people searching directly for an organisation’s accessibility information.
The statement itself should be accessible in its delivery format. Publishing it as HTML is usually more compatible than a PDF because it supports responsive layout, semantic headings, and direct navigation with assistive technology. If the organisation must provide PDFs, they should be supplementary and properly tagged. For many Squarespace sites, this means creating a standard page and ensuring the text is editable, searchable, and readable without downloading a file.
Accessibility statement placement tips:
Link to it from the footer site-wide so it is available on every page.
Use a consistent link label, such as “Accessibility statement”.
If the site serves multiple languages, publish equivalent translations and keep them aligned with the latest updates.
Gather feedback from real users.
An accessibility statement improves when it reflects real user experience, not just internal assumptions. People who use screen readers, voice input, captions, high contrast settings, keyboard-only navigation, or zoom regularly will notice barriers that automated tools miss. Their feedback can reveal practical breakdowns like confusing focus order, missing error summaries, or interactions that time out too quickly.
Feedback also acts as an early warning system. If several people report that checkout buttons cannot be activated on mobile with assistive touch settings, that is not just a compliance issue, it is lost revenue and reputation damage. When feedback loops are present, teams can prioritise fixes based on real-world impact rather than guessing. This is particularly valuable for founders and small teams who need to focus limited engineering time on what moves the needle.
Mechanisms should be simple and safe. A dedicated email address, an accessible contact form, and a clear description of what information helps (page URL, device, browser, assistive tech) can turn vague complaints into actionable bug reports. For operations teams running automation through platforms such as Make.com, routing these reports into a triage board (with categorisation and status updates) can prevent issues from getting lost.
Strategies for gathering feedback:
Run periodic user testing sessions that include participants with disabilities and diverse assistive tech setups.
Use short surveys focused on critical journeys, such as booking, checkout, or account management.
Invite feedback through channels where the community already speaks, such as social platforms or forums, then consolidate it into a single internal queue.
Update it as the site changes.
An accessibility statement is only reliable if it stays current. Websites evolve through redesigns, content refreshes, new embeds, and third-party widgets. Each change can introduce regressions, such as broken heading structure, poor contrast in a new button style, or missing labels in a new form integration. Treating the statement as a living document ensures it remains a dependable source of truth.
A review cadence helps. Quarterly reviews work for fast-moving teams, while biannual reviews can suit stable brochure sites, provided updates also happen after major releases. Ownership matters more than frequency. The statement should have a named owner, even if that owner is a small team wearing multiple hats. Without ownership, statements tend to drift into being outdated, generic, and legally risky.
Updates should reflect what changed, not just the date. If a known limitation is resolved, it should be removed or moved to a “recent improvements” note. If new barriers appear, they should be added with workarounds. When organisations run multiple properties, a lightweight changelog process can reduce confusion, ensuring that the marketing site and product site do not contradict each other.
Considerations for updates:
Review after redesigns, navigation changes, major content migrations, or new checkout flows.
Adjust claims when compliance levels change, whether improving or temporarily regressing.
Fold validated user feedback into the next revision and acknowledge fixes where appropriate.
Promote awareness internally and externally.
Publishing the statement is only the first step. It becomes useful when people know it exists and understand what it is for. External awareness helps users find support quickly, and internal awareness helps staff respond consistently when questions arrive through email, chat, or social channels. This is where accessibility moves from “a page on the site” to an operational habit.
Teams often underinvest in internal enablement. Staff should know what the organisation claims, what the known issues are, and how to escalate reports. For founders and SMBs, this can be a short internal guide linked in onboarding materials. For agencies and SaaS teams, it can be a runbook that lives with other operational docs. The aim is consistency: no one should promise a feature is accessible when the statement clearly flags it as a limitation.
External promotion can be light-touch and still effective. A mention in newsletters, a short note in release updates, or a link in a help centre footer can drive awareness without turning accessibility into marketing theatre. When improvements are shipped, sharing what changed is often more meaningful than repeating broad claims.
Ways to promote awareness:
Include the statement and escalation process in employee onboarding or team handover notes.
Reference updates when accessibility improvements are released, using plain descriptions of what changed.
Add the link to help pages, support replies, and relevant automated messages where users commonly get stuck.
Measure whether it is working.
The statement should reduce confusion, support self-service, and improve trust. Measuring effectiveness turns it from a compliance artefact into a performance tool. Basic signals include how often the page is viewed, whether visitors scroll or click contact links, and how many accessibility reports arrive over time. A rise in reports is not always bad; it can mean users finally know where to go.
Pair quantitative signals with qualitative insight. Analytics might show the statement is rarely visited, but support might report repeated accessibility-related questions. That gap suggests the link is hard to find or the wording does not match user language. Conversely, if the statement gets visits after a redesign, it could signal new friction that needs attention. Metrics only matter when they are tied to actions, such as prioritising a fix, updating wording, or improving link placement.
Teams can also track resolution time for reported issues and whether recurring complaints decline after fixes are deployed. For organisations using structured data systems such as Knack, logging issue type, page, severity, and resolution outcome in a database can turn accessibility maintenance into an operational workflow rather than scattered inbox threads.
Metrics to consider:
Page views, navigation paths to the statement, and click-through rate to contact or help links.
Volume, category, and severity of reported accessibility issues over time.
Time to acknowledge and resolve issues, and whether repeat reports drop after fixes.
Accessibility statements work best when they read like a helpful support page backed by clear commitments. They set expectations, reduce friction, and create a feedback loop that improves the site over time. The next step is translating these best practices into what the statement actually contains, including a practical template of sections and the operational processes that keep it accurate as the website evolves.
Frequently Asked Questions.
What is the purpose of an accessibility statement?
An accessibility statement outlines a website's commitment to inclusivity, detailing how accessible the site is and what support is available for users with disabilities.
Why are accessibility statements important?
They foster trust, enhance user experience, and demonstrate an organisation's commitment to social responsibility, making them essential for all digital platforms.
How often should an accessibility statement be updated?
Accessibility statements should be updated regularly, especially after major website changes or audits, to ensure they reflect the current state of accessibility.
What should be included in an accessibility statement?
It should include the organisation's commitment to accessibility, known limitations, available support, and contact information for reporting issues.
How can organisations ensure compliance with accessibility standards?
By adhering to the Web Content Accessibility Guidelines (WCAG) and conducting regular audits, organizations can maintain compliance and improve accessibility.
What are the legal implications of not having an accessibility statement?
Lack of an accessibility statement can lead to legal issues, as it may indicate non-compliance with accessibility laws and regulations.
How can user feedback improve accessibility efforts?
User feedback provides insights into real-world usability challenges, helping organizations prioritize improvements and enhance the overall user experience.
What role do audits play in maintaining accessibility?
Regular audits help identify areas for improvement, ensuring compliance with accessibility standards and informing updates to the accessibility statement.
How can organisations promote their accessibility statement?
By integrating information about the accessibility statement into marketing materials, training staff, and ensuring visibility on the website, organisations can raise awareness.
What is the significance of using plain language in accessibility statements?
Using plain language ensures that the statement is easily understood by all users, making it more effective in communicating the organization's commitment to accessibility.
References
Thank you for taking the time to read this lecture. Hopefully, this has provided you with insight to assist your career or business.
European Union. (n.d.). Accessibility statement of EU website. European Union. https://european-union.europa.eu/accessibility-statement_en
W3C. (n.d.). Developing an accessibility statement. W3C. https://www.w3.org/WAI/planning/statements/
GOV.UK. (2019, May 17). Make your website or app accessible and publish an accessibility statement. GOV.UK. https://www.gov.uk/guidance/make-your-website-or-app-accessible-and-publish-an-accessibility-statement
Eye-Able. (n.d.). Accessibility statement explained in simple terms: content, obligations, examples. Eye-Able. https://eye-able.com/blog/accessibility-statement
A11Y Collective. (2025, February 7). How to write a legal website accessibility statement. A11Y Collective. https://www.a11y-collective.com/blog/website-accessibility-statement/
Letslaw. (2024, December 5). Obligations for web accessibility. Letslaw. https://letslaw.es/en/wen-accessibility-persons-disabilities/
UK Parliament. (n.d.). Accessibility statement. UK Parliament. https://www.parliament.uk/site-information/accessibility/
Termly. (2025, September 10). What is an accessibility statement & how to make one. Termly. https://termly.io/resources/articles/what-is-an-accessibility-statement/
LexisNexis. (2015, July 3). What is a website accessibility statement? LexisNexis. https://www.lexisnexis.co.uk/legal/guidance/what-is-a-website-accessibility-statement
Tu Web Accesible. (2024, October 14). Web accessibility is already mandatory for private companies - 2025. Tu Web Accesible. https://www.tuwebaccesible.es/en/web-accessibility-is-already-mandatory-for-private-companies/
Key components mentioned
This lecture referenced a range of named technologies, systems, standards bodies, and platforms that collectively map how modern web experiences are built, delivered, measured, and governed. The list below is included as a transparency index of the specific items mentioned.
ProjektID solutions and learning:
CORE [Content Optimised Results Engine] - https://www.projektid.co/core
Cx+ [Customer Experience Plus] - https://www.projektid.co/cxplus
DAVE [Dynamic Assisting Virtual Entity] - https://www.projektid.co/dave
Extensions - https://www.projektid.co/extensions
Intel +1 [Intelligence +1] - https://www.projektid.co/intel-plus1
Pro Subs [Professional Subscriptions] - https://www.projektid.co/professional-subscriptions
Web standards, languages, and experience considerations:
ARIA
HTML
WCAG
WCAG 2.2 Level AA
Browsers, early web software, and the web itself:
Chrome
Firefox
Safari
Devices and computing history references:
Android
iOS
macOS
Windows
Accessibility laws and regulations:
Americans with Disabilities Act (ADA)
EU Web Accessibility Directive
European Accessibility Act
Platforms and implementation tooling:
Google Search Console - https://search.google.com
Knack - https://www.knack.com
Make.com - https://www.make.com
Squarespace - https://www.squarespace.com
Assistive technologies and screen readers:
Dragon - https://www.nuance.com
NVDA - https://www.nvaccess.org
TalkBack - https://support.google.com
VoiceOver - https://www.apple.com
