惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
V2EX
C
Check Point Blog
博客园 - Franky
月光博客
月光博客
T
Tenable Blog
博客园 - 聂微东
Cyberwarzone
Cyberwarzone
The GitHub Blog
The GitHub Blog
C
CERT Recently Published Vulnerability Notes
Scott Helme
Scott Helme
IT之家
IT之家
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
C
CXSECURITY Database RSS Feed - CXSecurity.com
F
Full Disclosure
博客园 - 司徒正美
Project Zero
Project Zero
Y
Y Combinator Blog
A
Arctic Wolf
美团技术团队
博客园 - 叶小钗
S
Securelist
F
Fortinet All Blogs
T
Threatpost
T
Threat Research - Cisco Blogs
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
酷 壳 – CoolShell
酷 壳 – CoolShell
MyScale Blog
MyScale Blog
大猫的无限游戏
大猫的无限游戏
Recorded Future
Recorded Future
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
S
Schneier on Security
Apple Machine Learning Research
Apple Machine Learning Research
L
LangChain Blog
P
Privacy International News Feed
博客园_首页
S
SegmentFault 最新的问题
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
腾讯CDC
P
Proofpoint News Feed
Cisco Talos Blog
Cisco Talos Blog
AWS News Blog
AWS News Blog
阮一峰的网络日志
阮一峰的网络日志
G
Google Developers Blog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Simon Willison's Weblog
Simon Willison's Weblog
雷峰网
雷峰网
P
Proofpoint News Feed
Latest news
Latest news
G
GRAHAM CLULEY

TetraLogical Blog

Designing for people with reading disabilities - TetraLogical Designing for people who are D/deaf - TetraLogical Designing accessible documents - TetraLogical Introduction to creating accessible documents - TetraLogical Inclusive user research: vulnerable people - TetraLogical Designing for people who are blind - TetraLogical Designing for people with low vision - TetraLogical Meet the team: Niamh Madden - TetraLogical Designing for people with anxiety - TetraLogical Designing for people with disabilities - TetraLogical Accessible building blocks for the web videos - TetraLogical Common accessibility misconceptions - TetraLogical Common misconceptions about testing accessibility - TetraLogical Common misconceptions about implementing accessibility - TetraLogical Common misconceptions about WCAG - TetraLogical Common misconceptions about disability - TetraLogical Meet the team: Grace Snow - TetraLogical Sustainable accessibility in complex organisations: strategic foundations - TetraLogical Sustainable accessibility in complex organisations: organisational realities - TetraLogical Sustainable accessibility in complex organisations: external factors - TetraLogical Common misconceptions about screen readers - TetraLogical Guide to the Inclusive Design Principles - TetraLogical Meet the team: Ian Lloyd - TetraLogical Annotating designs using common language - TetraLogical Meet the team: Catriona Morrison - TetraLogical Championing inclusive language - TetraLogical Press release: TetraLogical launches accessible self-led training courses to help digital teams build confidence in accessibility - TetraLogical Why inclusive products are green products - TetraLogical Accessible Recruitment - TetraLogical Accessibility and the agentic web - TetraLogical Meet the team: Craig Abbott - TetraLogical Foundations: types of assistive technology and adaptive strategies - TetraLogical European Accessibility Act (EAA) FAQ - TetraLogical Screen reader HTML support tables - TetraLogical Interview with Lola Odelola - TetraLogical Inclusive user research: building rapport - TetraLogical Foundations: Keyboard accessibility - TetraLogical Can generative AI write contextual text descriptions? - TetraLogical Understanding the European Accessibility Act (EAA) - TetraLogical Meet Josh: a sportsman who has spinal muscular atrophy - TetraLogical Meet Jonathan: a photographer who has ADHD - TetraLogical Foundations: grouping forms with `<fieldset>` and `<legend>` - TetraLogical XR Accessibility: for people with moving disabilities - TetraLogical Meet Andre: a music producer and blind screen reader user - TetraLogical Foundations: types of disability - TetraLogical Meet Lauren: a film editor who has ADHD - TetraLogical Meet Steve: a photographer who is deaf and low vision - TetraLogical Foundations: form validation and error messages - TetraLogical Meet Hasmukh: a blind cricketer and screen reader user - TetraLogical XR Accessibility: for people with hearing disabilities - TetraLogical XR Accessibility: for people with thinking disabilities - TetraLogical XR Accessibility: for people with seeing disabilities - TetraLogical Introduction to XR Accessibility - TetraLogical Foundations: labelling text fields with input and label - TetraLogical Design patterns and WCAG - TetraLogical Does WCAG 2.2 apply to native apps - TetraLogical Why are my live regions not working? - TetraLogical Building a culture of accessibility - TetraLogical When to use tabindex= Accessibility foundations - TetraLogical Meet the team: Demelza Feltham - TetraLogical Can generative AI help write accessible code? - TetraLogical Meet the team: Steve Faulkner - TetraLogical Meet the team: Gez Lemon - TetraLogical Keyboard accessibility myths and WCAG - TetraLogical Amendment to the Public Sector Accessibility Regulations - TetraLogical What Considerations for TV user interface accessibility - TetraLogical Meet the team: Alistair Duggin - TetraLogical Sticky content: focus in view - TetraLogical The only accessibility specialist in the room - TetraLogical Meet the team: Ian Pouncey - TetraLogical Meet the team: Dean Holden - TetraLogical Meeting WCAG Level AAA - TetraLogical Foundations: accessible names and descriptions - TetraLogical Inclusive XR: accessible augmented reality experiences - TetraLogical Foundations: pointer gestures - TetraLogical Meet the team: Graeme Coleman - TetraLogical Adding sign language to videos - TetraLogical Foundations: introduction to WAI-ARIA - TetraLogical Meet the team: Joe Lamyman - TetraLogical Inclusive XR: accessible 3D experiences - TetraLogical Foundations: visible focus styles - TetraLogical Foundations: target sizes - TetraLogical Meet the team: Henny Swan - TetraLogical Meet the team: Ela Gorla - TetraLogical Foundations: native versus custom components - TetraLogical Foundations: HTML semantics - TetraLogical Accessibility and supporting Internet Explorer - TetraLogical Meet the team: Felicity Miners-Jones - TetraLogical Accessibility and QR codes - TetraLogical Inclusive user research: recruiting participants - TetraLogical Research insight: accessibility of images - TetraLogical Meet the team: Léonie Watson - TetraLogical Android accessibility: roles and TalkBack - TetraLogical Accessible design systems - TetraLogical Meet the team: Patrick H. Lauke - TetraLogical Inclusive user research: analysing findings - TetraLogical How to write user stories for accessibility - TetraLogical Triaging WCAG 2.1 Level AAA - TetraLogical
Understanding EN 17161 Design for All - TetraLogical
Clause 5.3: Organisational roles, responsibilities and authoriti · 2025-06-27 · via TetraLogical Blog

Posted on by Henny Swan in Standards, Strategy

While EN 301 549 is the technical standard cited in the European Accessibility Act (EAA), EN 17161 Design for All is a framework that supports embedding accessibility into strategy, design, and development processes.

Both are harmonised standards used by the EAA and yet all the focus has been on EN 301 549. This post explores how the two standards relate to each other, and what that means for providers of digital products and services.

Sustainable accessibility: an outline of a muted purple tree with two branches on either side of the trunk. At the ends of the branches are bright purple or red gears which interlock and rotate with the gear above or below it. There are two bright orange leaves growing at the top of the tree and a single leaf towards the bottom.
Sustainable accessibility

In brief

As outlined in Understanding the EAA by Léonie Watson, we interpret the EAA's requirements for digital products and services to mean that economic operators and service providers should take the following steps to maximise their conformance with the Act:

  • Use EN 17161 Design for All to put in place processes and practices that enable continuing conformance with the accessibility requirements
  • Use EN 301 549 and the functional performance criteria in Annex I to demonstrate conformance with the accessibility requirements
  • Document how services conform to the accessibility requirements, and how processes and monitoring help achieve conformance
  • If warranted, carry out a disproportionate burden assessment, and report to all national authorities where the product or service is available if an exemption is claimed

For the purposes of this post, we will refer to EN 17161 Design for All, as Design for All.

Availability

Design for All is a paid for standard available from a number of places at a range of prices.

Purpose

The purpose of Design for All is to help organisations embed accessibility into their management systems, ensuring that accessibility is considered from strategy and planning through to implementation and review.

Scope

Design for All is applicable to all organisations regardless of type, size or sector. It supports making products, goods, services, and environments accessible and usable by as many people as possible, including disabled and older people.

Key points

Focus

Design for All is a framework of process requirements that complements EN 301 549, the technical standard referenced in the EAA. As such it emphasises how to integrate accessibility considerations into seven areas which are outlined in clauses 4 to 10:

  • Context of the organisation
  • Leadership
  • Planning
  • Support
  • Operation
  • Performance evaluation
  • Improvement

User involvement

Design for All has a strong emphasis on the importance of involving a diverse range of people, particularly people with disabilities, in the design and evaluation process.

This is covered in detail in Annex C where it describes including people with disabilities in the design process in the following ways:

1. Understand who will use it and how

Understand who your audience is and in what situations they'll be using the product or service.

2. Learn what users need and want

Get a clear picture of what matters to people, including their goals, preferences, abilities, and limitations, so these can shape the design and requirements.

3. Design something that works for them

Create solutions that match what people need and expect, based on what you've learned.

4. Check if it actually works for users

Test the solution with people to see if it meets their needs and works well for them, and check whether it matches the original goals.

Compatibility

The Design for All approach is intended to align with other management system standards such as ISO 9001, making it easier for organisations already following such frameworks to incorporate accessibility.

Supports compliance with the EEA

EN 17161 Design for All, is already a recognised standard that can be used to demonstrate conformance with the EAA. A revised version is planned for publication in September 2025.

Clauses and requirements

Clauses 4 to 10, describe areas an organisation can focus on in order to adopt the Design for All approach.

Clause 4: Design for All approach

The Design for All approach focuses on how organisations can embed accessibility into their operations. It sets the foundation for making accessibility a consistent part of strategy, design, and delivery, particularly in the context of digital and physical products, services, and environments.

Clause 4.1: Accessibility following a design for all approach

Design for All is about making products and services work for as many people as possible including older people, and different types of disability including people with seeing, hearing, moving, or thinking disabilities.

It means thinking about accessibility and usability from the very beginning, and keeping it in mind through every stage of the product or service lifecycle.

The Design for All approach doesn't mean everything has to be identical for everyone. It means making sure people can:

  • Access it: find it and take it in
  • Understand it: know what it's for and what to do
  • Use it: take action or respond in their own way

In short, it's about flexibility, not uniformity, so everyone gets a comparable experience, in a way that works for them.

Clause 4.2: Understanding the organisation and it's context

Organisations should make sure that all relevant policies, processes, and activities follow a Design for All approach. To do this well, they need a clear understanding of how their internal and external environments affects accessibility.

This includes:

  • User needs and preferences: what people require to access, understand, and use products and services
  • Feedback on existing products and services: what people are telling you about barriers and improvements
  • Legal and regulatory duties: national and international requirements for accessibility
  • Competitor practices: how others in the sector are addressing accessibility
  • Compatibility with assistive technologies: ensuring products work with tools people rely on
  • Changes in technology: keeping pace with new platforms, devices, and trends
  • Supply chain capability: what partners and suppliers can deliver in terms of accessibility
  • Economic, social, and cultural factors: broader issues that shape how people engage with your organisation

Clause 4.3: Understanding the needs and expectations of interested parties

Organisations should identify who uses their products and services, who is excluded, and why.

Organisations should:

  • Identify who uses the product: including those who use the product or service directly, and those who support others to use it
  • Understand who is not using it: especially where accessibility may be a barrier
  • Plan for inclusion: identify what needs to change to help more people access, understand, and use the product or service
  • Consider delivery needs: take into account the needs of anyone involved in delivering or supporting the service
  • Review regularly: keep this information up to date as things change

Clause 4.4: Determining the scope of the Design for All approach within the organisation

Organisations should decide how and where their Design for All approach will apply.

Organisations should consider:

  • Internal and external factors: identified in Clause 4.2
  • People's needs and expectations: described in Clause 4.3

Clause 4.5: Integration with established process systems

Design for All works best when it's part of everyday practice, not treated as an add-on. To make this happen, accessibility should be built into existing processes and systems.

Organisations should:

  • Understand and address accessibility needs: make sure everyone knows what's required and why it matters
  • Recognise the value of inclusion: help all teams see the benefit of reaching more people
  • Embed accessibility into all processes: from design and development to delivery and support
  • Use feedback and data: learn from real experiences to improve products and services over time

Clause 5: Leadership

Leaders play a critical role in making accessibility part of how an organisation works. They need to set the vision, define policies, assign responsibilities, and provide the support and resources needed. A strong, well communicated commitment from the top makes it more likely that accessibility will be built into every part of the organisation.

Clause 5.1: Leadership and commitment

Senior leaders in the organisation must show clear commitment to accessibility by creating an accessibility vision and goals to inspire employees and provide clear goals to measure progress against.

Leadership should show their commitment to accessibility by:

  • Investing in accessibility: providing enough time, money, and people
  • Setting clear goals: defining targets and how success will be measured
  • Making responsibilities clear: assigning ownership across teams
  • Embedding accessibility into culture: encouraging everyone, from planning and design to marketing to take part
  • Creating space for innovation: supporting new ideas to improve accessibility and reach more people
  • Supporting continuous improvement: reviewing progress and identifying areas to grow
  • Monitoring activity: keeping track of design and development decisions
  • Linking accessibility to brand and reputation: using accessibility as a way to build trust and reach more customers
  • Building capability: identifying training needs and recruiting people with the right skills

Making accessibility happen takes both a top-down and bottom-up effort. Product teams can lead the way, but real impact depends on strong support from leadership. Senior decision makers play a critical role in setting direction, removing barriers, and making accessibility part of how things are done.

Clause 5.2: Policy

Leadership should create an accessibility policy that:

  • Shows commitment: focuses on improving access, understanding, and use by people with disabilities
  • Applies across the organisation: is scoped to be used across all teams, products, and services
  • Drives continuous improvement: supports learning and progress over time
  • Fits the organisation's purpose: is aligned with goals, values, and the business context
  • Gets reviewed regularly: is updated when things change or new needs emerge
  • Is shared openly: is understood by everyone inside the organisation, and outside, when relevant

Leadership should clearly assign and communicate responsibility for accessibility by:

  • Defining accountability: making it clear who is responsible for improving accessibility and reaching more users
  • Checking effectiveness: making sure accessibility efforts are working as intended
  • Keeping users in focus: ensuring all teams consider a wide range of user needs
  • Building understanding: helping staff recognise the value of designing for different characteristics, abilities, and preferences

Clause 6: Planning

Planning for accessibility means thinking about risks, opportunities, goals, and changes. Organisations should set clear objectives, build accessibility into all relevant processes, and be ready to adapt while protecting accessibility outcomes. A planned, proactive approach ensures more people can use products and services effectively, now and in the future.

Clause 6.1: Actions to address risks and opportunities

When planning a Design for All approach, organisations should consider internal and external factors (clause 4.2) and user needs and expectations (clause 4.3) to:

  • Support accessibility goals: make sure policies and processes can deliver what's needed
  • Avoid problems: reduce the risk of missing user needs or accessibility targets
  • Use opportunities: find ways to attract new users or explore new service areas
  • Reach more people: keep expanding who can access, understand, and use products and services

Organisations should also:

  • Plan specific actions: address risks and opportunities directly
  • Embed actions into everyday work, including:
    • recruitment and hiring
    • disability knowledge and lived experience
    • user involvement and feedback
    • product and service design
    • manufacturing and delivery
    • work with external providers
    • packaging and presentation
  • Evaluate impact: check how well actions are working
  • Track barriers: collect and review information on what prevents people from accessing, understanding, or using the organisation's products and services

Clause 6.2: Design for All approach objectives and planning to achieve them

Organisations should set clear accessibility goals across relevant teams and levels that:

  • Align with the vision and policy: reflect the organisation's purpose (clause 5.2)
  • Are measurable: define clear outcomes where possible
  • Meet requirements: cover both legal and organisational needs
  • Are tracked and reviewed: checked regularly to monitor progress
  • Are clearly communicated: shared across the whole organisation

To meet these goals, organisations should plan:

  • What needs to happen: define the specific actions
  • What resources are needed: identify time, money, and people
  • Who is responsible: assign clear accountability
  • When it will happen: set realistic timelines
  • How success will be measured: agree what good looks like

Clause 6.3: Planning for changes

Organisations should plan for any changes that could affect accessibility or their Design for All approach. Changes to policies, processes, or activities must be managed carefully and with a clear plan (clauses 4.2 and 4.3).

When planning changes, organisations should:

  • Understand the reason for change: know why it's needed and how it could affect people
  • Assess the potential impact, including:
    • The overall Design for All approach
    • The accessibility of products and services
  • Check available resources: identify what time, people, or budget will be needed
  • Review roles and responsibilities: decide if any changes are needed in who does what

Clause 7: Support

Organisations need to put the right resources, skills, communication, and documentation in place to support their Design for All approach. This means making sure teams are informed, trained, and equipped. And that decisions and actions are clearly recorded and reviewed.

Clause 7.1: Resources

Organisations should provide the right resources to support a Design for All approach and meet accessibility goals. This means making sure the right people, tools, and systems are in place at every stage.

Organisations should:

  • Review what's already in place: assess internal skills, tools, and infrastructure
  • Identify what's missing: decide what support or expertise is needed from outside
  • Make use of existing knowledge: identify and apply what's already known about accessibility and inclusion
  • Support inclusive design infrastructure: build and maintain systems that make accessible ways of working possible
  • Match resources to each stage: identify resources for design through to delivery and monitoring
  • Fund measurement and tracking: allocate time and money to measure progress and impact

Clause 7.2: Competence

Organisations should make sure everyone involved in Design for All has the right knowledge, skills, and experience. This helps teams make informed decisions and deliver accessible outcomes.

Organisations should:

  • Identify required skills: understand what capabilities are needed across roles
  • Provide ongoing training: keep staff up to date with regular learning and development

Clause 7.3: Awareness

Everyone involved, including employees and suppliers, should understand their role in supporting a Design for All approach. Clear communication helps build shared responsibility and sustained progress.

Organisations should make sure people are aware of:

  • The vision and policy: as set out in clause 5.2
  • Accessibility objectives: defined in clause 6.2
  • Their role and responsibilities: how they contribute to an inclusive culture
  • Performance feedback: how well their work supports accessibility outcomes

Clause 7.4: Communication

Organisations should plan how they communicate about Design for All and accessibility, both internally and externally. Good communication builds awareness, accountability, and trust.

Organisations should:

  • Decide what to share: choose the most relevant and useful information
  • Plan when and how to share it: use the right timing and channels for each audience
  • Identify who needs to know: make sure the right people receive the right messages

All communication should be clear and accessible.

Clause 7.5: Documented information

Organisations should create and maintain key documents that support their Design for All approach. These documents help track progress, guide decisions, and show accountability.

Organisations should include documentation that covers:

  • Interested parties and their needs: who uses their products and services as outlined in Clause 4.3
  • The scope of the approach: where and how Design for All applies (clause 4.4)
  • The vision and policy: setting direction and intent (clause 5.2)
  • Accessibility goals: what the organisation aims to achieve (clause 6.2)
  • Supporting processes: systems in place to deliver on accessibility (clause 8.1)
  • User needs in design: how people's requirements are included (clause 8.2.3)
  • Accessibility evaluations: how accessible products and services are assessed (clause 8.2.5)
  • Accessibility across the user journey: from start to finish (clause 8.4)
  • Monitoring and measurement: how progress is tracked (clause 9.1)
  • The assessment process: and the outcomes (clause 9.2)
  • Decisions and actions for improvement: what's been done in response (clause 9.3)
  • Updates and improvements: any changes made over time (clause 10)
  • Other relevant documentation: anything else the organisation deems necessary

Clause 8: Operation

Accessibility needs to be part of every stage of a product or service, from design through to launch. Organisations should understand who their users are, include them early on, and think about their needs at each step. Testing, clear communication, and working closely with suppliers all help make sure the whole user journey is accessible.

Clause 8.1: Operation planning and control

Organisations should embed Design for All into everyday operations. This helps make accessibility a consistent part of how work gets done.

Organisations should:

  • Set clear ways of working: define rules and expectations
  • Check regularly for consistency: make sure teams follow agreed processes
  • Manage change: plan for changes and respond to unexpected issues (clause 6.3)
  • Hold suppliers to the same standard: ensure external partners meet accessibility requirements

Clause 8.2: Design and development of products and services

Clause 8.2.2: Identifying the intended users
Clause 8.2.2.1: Establishing users and non-users

Organisations should understand who can, and can't, use their products and services. This helps identify barriers and uncover opportunities to improve accessibility.

Organisations should:

  • Identify who is and isn't using what they offer: including direct and indirect users
  • Find out why some people are excluded: collect insights from those affected through user research, usability testing, and feedback loops
  • Use multiple sources: look at internal data and external research
  • Analyse the information: organise and curate insights and use them to fill any knowledge gaps
Clause 8.2.2.2: Specifying the intended users

Organisations must clearly define who the intended users are, making sure this includes the widest possible range of people, including those who access products indirectly for example through another person or device.

Clause 8.2.2.3: Identifying the needs, characteristics and capabilities of the intended users

Organisations must:

  • Recognise diverse user needs: consider differences in age and physical, sensory, mental, and cognitive capabilities
  • Identify the context of use: including location, environment, and typical tasks
  • Understand the relationship between needs and context: how different environments and situations affect what people need from a product
Clause 8.2.3: Requirements to extend the range of users

Design specifications must include:

  • User requirements: based on identified user needs
  • Legal and regulatory requirements: including relevant laws and regulations
  • Applicable standards and guidance: such as accessibility and usability standards
  • Information on barriers and assistive technologies: to help reduce or remove barriers
  • Compatibility with assistive technology: including interoperability considerations
  • Insights from earlier analysis: drawing on findings from user research (clause 8.2.2)
Clause 8.2.4: Realisation
Clause 8.2.4.1: Developing solutions

Organisations should:

  • Use reliable user information: based on evidence rather than assumptions
  • Follow best practices: in accessibility and inclusive design
  • Gather and apply user feedback: including feedback from people who use assistive technologies
  • Use an iterative design process: test, improve, and repeat
  • Ensure equal treatment: for people who use assistive technologies
  • Maximise compatibility: by using open standards that support assistive technology
Clause 8.2.4.2: Approaches to design solutions to achieve accessibility outcomes

Designs should:

  • Offer multiple ways to interact: so people can access and use content in different ways
  • Support flexibility:so people can adjust the design to suit their needs
  • Reduce complexity: by keeping interactions simple and avoiding unnecessary steps
  • Enable personalisation: so people can tailor access to their needs
  • Avoid unnecessary limits: that restrict how people interact with the product
  • Be compatible with assistive technology: ensuring smooth use with a wide range of hardware and software
Clause 8.2.5: Evaluation

Organisations must evaluate their products and services to check they meet accessibility goals.

This includes reviewing:

  • Early concepts: to identify issues from the start
  • Prototypes: to test ideas before development progresses
  • Technical specifications: to ensure accessibility is built into the foundations
  • Design alignment: checking how well the product matches its intended design
  • Usability testing with disabled people: to understand real-world accessibility

Testing and evaluation should take place during development and between product versions.

Clause 8.3: User involvement

Organisations must involve disabled people as early as possible in design and development.

This includes:

  • Identifying user needs and preferences: to shape inclusive solutions from the start
  • Gathering feedback on barriers and opportunities: to understand what helps or hinders access
  • Identifying relevant assistive technologies: that people use to interact with products
  • Involving users in testing and evaluation: to check how well the design works in practice

Clause 8.4: End-to-end chain in relation to accessibility

Organisations must think about accessibility across the whole user journey, not just the product itself. This means identifying:

  • Where the biggest barriers exist: across different stages of the journey
  • How mature each part is: in terms of accessibility readiness
  • Who controls each stage: whether internal teams or external partners
  • How external factors affect access: such as packaging, instructions, and customer support

Both internal and external factors should be reviewed, including:

  • Pre-sale and purchase: how people find, choose, and buy the product
  • Installation and setup: how easily the product can be put into use
  • Post-sale support and warranty: how help and repairs are handled

The organisation must assess these factors and use the findings to support:

  • Stakeholder needs: as outlined in clause 4.3
  • Scope definition: as outlined in clause 4.4
  • Planning and design: as outlined in 6.1, 6.2, and 8.2
  • Evaluation and improvement: as outlined in 8.2.5, 9.1, and 9.2

Clause 8.5: Control of and communication with external suppliers

Organisations must set clear accessibility and usability requirements for suppliers and communicate:

  • What is expected: outlining their responsibilities clearly
  • How they contribute: to meeting end-to-end accessibility

This helps ensure that externally sourced products or services still support the organisation's accessibility vision and goals.

Clause 9: Performance evaluation

Organisations need to keep checking how well their Design for All approach is working. This includes measuring what's happening, listening to users, and tracking progress. Regular internal checks and reviews by leaders help make sure the organisation stays on track and makes products and services more accessible to more people over time.

Clause 9.1: Monitoring, measurement, analysis and evaluation

Clause 9.1.1: General

Organisations must regularly monitor, measure, analyse, and evaluate how well their Design for All approach is working.

This helps them check if they are:

  • Meeting accessibility goals: by tracking progress against targets
  • Following planned processes: to maintain consistency and quality
  • Achieving intended results: by measuring impact on users

They must:

  • Decide what to monitor and measure: linked to the organisation's policy (clause 5.2) and objectives (clause 6.2)
  • Use reliable methods: to collect and assess meaningful data
  • Check real-world access and use: whether products and services are being accessed, understood, and used by as many people as possible
  • Evaluate effectiveness: using the results to assess how well the Design for All approach is working

Monitoring helps track whether more people are able to use a product or service and where improvements may be needed (clause 10).

Clause 9.1.2: User feedback

Organisations must collect feedback from users, including people with disabilities, to understand whether their needs are being met.

This includes:

  • Involving a diverse group: especially people who may not usually take part
  • Offering multiple feedback options: such as online, phone, or in-person
  • Using feedback to improve: policies, processes, and products
Clause 9.1.3: Analysis and evaluation

Organisations must analyse the data they collect to:

  • Show compliance: demonstrating that products and services meet Design for All requirements
  • Improve customer satisfaction: by responding to real user experiences
  • Assess effectiveness: checking how well the overall approach is working
  • Review supplier performance: evaluating how well external partners are delivering
  • Identify process improvements: finding areas that need change or refinement

The results from this analysis feed into management decision-making and help guide further actions.

Clause 9.2: Internal audit

Organisations must evaluate its own processes and systems regularly to check whether:

  • Practices match policies: ensuring alignment with their own Design for All commitments
  • Requirements are met: confirming compliance with this standard
  • The approach is maintained: checking that it's being properly followed over time

They must:

  • Share results with relevant managers: so findings are acted on
  • Take corrective action: to fix problems and prevent them happening again

Clause 9.3: Management review

Senior leaders must regularly review:

  • Design for All policy and goals: as set out in clauses 5.2 and 6.2
  • Performance and audit results: including findings from evaluations and internal audits (clauses 9.1 and 9.2)

These reviews should cover:

  • Progress on previous actions: tracking follow-up and results
  • Relevant changes: both internal and external
  • Effectiveness of the approach: how well Design for All is being applied
  • Trends and indicators, such as:
    • Accessibility outcomes
    • User feedback
    • Supplier performance
    • Internal audit findings
  • Opportunities for improvement: and how well risks and opportunities have been addressed

The review must lead to clear decisions and actions to improve accessibility and extend the range of users. Leadership is also responsible for ensuring the organisation has the resources needed to carry out these improvements.

Clause 10: Improvement

Organisations must treat accessibility as an ongoing effort. That means acting on feedback, checking progress, and always looking for better ways to meet users' needs. Improvements should be based on evidence and regularly checked for impact.

This means they must:

  • Identify areas to improve: across processes, procedures, and activities
  • Take action: to make those improvements
  • Check the results: to see if the changes worked as expected

Improvements should be guided by:

  • Management review outcomes: outlined in clause 9.3
  • Accessibility goals and objectives: outlined in clause 6.2
  • Performance evaluations: outlined in clause 9.1
  • Internal audit results: outlined in clause 9.2
  • Data analysis: that highlights problems or opportunities

As well as evaluating its performance against the Design for All approach (Clasue 9.2), organisations can also carry out assessment of products and services in order monitor progress and improvements.

Next steps

For more information, read Understanding the EAA by Léonie Watson or find out more about how our Agile Usability Testing service and Consultancy services can help you meet your EAA goals.