Embedding Accessibility Earlier in Projects

1 Comment / By /
The DTA project lifecycle with growing amount of users being engaged as the project progresses through all the phases
DTA Service Design and Delivery Process with an arrow showing the need to embed accessibility across all phases

Introduction

To ensure the ‘shift-left’ of accessibility the focus is more on how to involve People with Disability earlier in a project process rather than testing for accessibility (rather than only providing an audit report too late in the project). We look at some practical ways that can be used to assess how the project is tracking against compliance in the early phases of the lifecycle.

Key to this is the use of Government and organisation standards criteria and design systems which are now becoming more available for project teams to embed accessibility into the project lifecycle to ensure they are developing inclusive products and services.

“Accessibility isn’t just about wheelchairs or screen readers.
Accessibility is about optimising the experience to include as many people as possible.”

Quote from Laura Kalbag, 2014

Get involved in OZeWAI projects

If you wish to be involved in further work on this checklist or be involved in other OZeWAI projects, please refer to the OZeWAI Membership tiers information, join OZeWAI or contact us to discuss becoming a project partner.

Training and resources

One benefit for considering accessibility earlier is to reduce cost in the development stage but there are many other benefits and reasons that are shared by OZeWAI members and supporters and other Accessibility professionals.  OZeWAI also shares ways to develop the skills and knowledge to embed accessibility in your organisations and project teams:

Relevant articles on embedding accessibility earlier

Accessibility checks for organisations and project teams

It’s not only going to be one thing! Included are the top 3 responses and each step includes additional considerations.

This list provides some of ideas of how to go about checking earlier for digital/web accessibility. Further work is needed to be more inclusive for physical or hybrid services and products.

Approach and methodology

This article provides a summary of results of a workshop held at the Perth Web Accessibility Camp (PWAC) which crowd-sourced guidance on how to assess accessibility during the different project phases.

The workshop referenced the Digital Transformation Agency’s Digital Service Standard and identified what specific ways you can test for accessibility during the Service Design and Delivery Process, and where the WCAG criteria is relevant as an ongoing accessibility audit. This approach can also be aligned to assess digital services and products for State Government and organisations’ design standards criteria.

OZeWAI members have also been involved in assessment of projects that have included either accessibility professionals embedded in teams and/or involved in the assessment approach. This material brings together a culmination of work to help project teams consider inclusive and accessible practices, such as inclusive research and accessibility assessments of user research and design, not just development.

Pre-discovery and Discovery phases

Business case

  1. Ensure meeting WCAG 2.1 is a non-negotiable requirement!
  2. Community engagement.
  3. Co-design with people with lived experience.

Other considerations:

  • Financial modeling
  • Case studies and examples
  • Risk analysis or an Accessibility policy
    • Build research around impact, particularly ROI for easier adoption by boards
    • Inaccessible content means potential lost customers
    • This also means that you are out of touch of your target audience -lack of care.
  • Build out user scenario/story/requirements
  • Include practical examples of what accessibility means.

Before starting

  1. Ensure people understand what accessibility is.
  2. A diverse project team with an accessibility specialist.
  3. Include people with a disability at the very beginning, compensate them for their time and expertise.

Other considerations:

  • Building stakeholder buy in and understanding the value of accessibility for business and users
  • Make sure the correct budget is applied to the teams who need to spend it
  • Clear communications about time and scope throughout project
  • Identify stakeholders and SMEs that need to be engaged to ensure collaboration and that accessibility is considered earlier on
  • Work with the team to implement accessibility into your workflow

Onboarding & Kick Off

  1. Kick off workshop is inclusive and accessible e.g. making your powerpoint accessible.
  2. Kick off agenda addresses accessibility – set the expectation from the start that accessibility is important to the project’s success.
  3. Living your ideals and mission statements by hiring and using developers with lived experience.

Other considerations:

  • Cover expectations and goals within the team and for project outcomes
  • Add accessible documentation and include training for new team members to get up to speed

Research users

  1. Discuss specific accessibility requirements for key users and make those a priority.
  2. Discovery research on users. Who is our audience? What do they need?
  3. Include a broad range of disabilities in user research.

Other considerations:

  • Develop likely user profiles as pre-testing subjects
  • User journey map ideal experience
  • Stakeholder consultation
  • Review stats from existing sites
  • Create agreed upon definitions of user needs for a variety of background to fulfil community consultation

Research business

  1. Identify historical success and weaknesses – what are those who are failing doing (learn from their mistakes).
  2. Determine accessibility of current business systems.
  3. Determine whether service in-person has an accessible flow to web or online services.

Other considerations:

  • Analyse and predict impact of future technologies such as AI.
  • Look at getting user feedback and complaints on accessibility for existing systems
  • Competitive analysis – who is winning in A11y in allied (haw haw) experiences, services. What are they doing?

Map tech/data

  1. Analyse and score data and technology that are already used and what is proposed.
  2. Ensure your technology stack allows for rapid changing of underlying html code and tags.
  3. Ensure devs have accessible training and implementation experience.

Other considerations:

  • Ensure relevant data is identified and surfaced at appropriate times.
  • Identify accessibility tools to be used to check for accessibility during development (e.g. WAVE, axe, screen readers, HTML validators, etc.)

Identify hypotheses

  1. Write in plain language.
  2. Base user journeys on real life experiences.
  3. Check customer feedback for potential use cases.

Other considerations:

  • Ask people for feedback
  • Plan for how to add recommendations and improvements
  • Again, engage with PwD (possibly an advisory group). Listen to our needs. Then when you get feedback, LISTEN
  • Test assumptions with potential users
  • Why have a website? who will come? What do they want? Can we provide it?

Report findings/showcase

  1. Ensure reporting is written in plain language.
  2. Make findings easy to understand and tell a story.
  3. Making sure accessibility requirements are explained in terms everyone can understand.

Other considerations:

  • Follow reporting with clear steps for improvement
  • Stories are powerful – share stories from research participants with lived experience
  • Leverage storytelling and design artifacts that help communicate stories. Cater for your different audiences.

Preparing to hand over to Alpha

  1. Think about other peoples needs, and brainstorm ideas or issues that people might face.
  2. Adequate training to foster understanding and ongoing support within the business
  3. Documentation that’s clear and concise

Other considerations:

  • Check again success criteria and Definition of Done and can measure the evidence to move to Alpha

Alpha, Beta and Live

Onboarding and kick off of Alpha

  1. Reassess, redefine standards and guidelines the team has adhered to and making changes and decisions to make processes better.
  2. Are there any (non-WCAG) accessibility best practices that should be considered.
  3. Define how the team will track progress and track what has been achieved.

Other considerations:

  • Focus on the positive and encouraging elements. Carrots over sticks
  • What’s your minimal viable product (MVP) that must be covered by each prototype? Include core accessibility requirements
  • Train and educate project team on accessibility and to check for it.
  • Is the multidisciplinary team up-to-date with accessibility and do they understand the different ways people might interact with your design and build
  • Highlight that accessibility is a non-negotiable requirement

Build prototype

  1. Secure a test environment.
  2. Make sure the components you are using check off usability requirements (particularly if you are using a design system).
  3. Co-design workshop with people with lived experience.

Other considerations:

  • Prototype needs to be accessible in order to test with people with disability (sometimes people say we’ll address a11y later)
  • Make sure prototype design is inclusive
  • Compare and iterate designs to follow the standards and guidelines defined by the team
  • Use inbuilt accessibility features for your prototyping software (eg Figma).

Prepare for usability testing

  1. Ensure there is a wide variety of users with various levels of ability to be involved in usability testing.
  2. Ensure all the testers have adequate access to the alpha/beta systems so they have an experience as close to that of the end user.
  3. Test across different systems and tools.

Other considerations:

  • Consider any technical limitations / dev environments that may restrict you to in-person testing
  • Recruitment plan to ensure that you’re capturing a wide range of voices.
  • Prepare your screeners to ensure you’re getting the right participants for your sessions.
  • How do testers provide feedback?
  • Gather the latest statistics around what assistive tech is being used.
  • Define the tasks to be performed to illicit accessibility issues

Usability testing

  1. Pre-screen testing participants to ensure you are capturing a large breadth of users and accessibility needs.
  2. Make sure people with disabilities are included as testers.
  3. Create accessible documentation for users to learn how to use and navigate the service.

Other considerations:

  • How are you ensuring that the usability testing experience for participants is inclusive?
  • Check the website against WCAG Guidelines – manual and automated testing

Report test findings/showcase

  1. Storytelling – give people aha moments. help them connect to people on an emotional level.
  2. Again, ensure that report is written in plain language.
  3. Have recommendations/solutions to identified accessibility issues and suggest ways failed guidelines can be addressed, in plain English.

Other considerations:

  • Highlight potential accessibility issues
  • When presenting, ensure presenter is educated on accessible presentation, e.g. describing images and giving general overview of room
  • Ensure graphs and diagrams have appropriate alt text and key insights are explained in plain language
  • Share back with your research participants as well – keep people in the loop. they can become your biggest advocates

Iterate

  1. Don’t be afraid to go back a step.
  2. Review against the agreed guidelines. What went wrong? what is missing? What do we need?
  3. Iterate not just the product, don’t be afraid to bring up the shortcomings of processes, tools or guidelines.

Other considerations:

  • Ensure there’s a pipeline so that any issues can be addressed quickly rather than parked
  • Review documentation and ensure it is up to date
  • Entrophy is a disease, think link rot.
  • Be prepared to re-visit some or everything over time.
  • Iterate to a wide ranging audience – separate to usability testing
  • Iterate or pivot

Define MVP (“Be accessible” – Dr Manisha Amin)

  1. Accessible and usable.
  2. MUST be accessible.
  3. Define minimum WCAG Level that must be met for MVP (e.g. 2.1 Level AA).

Other considerations:

  • Simple isn’t it.
  • Define what browsers and or platforms you will be building for, to be sure that the final product is tested one those

Preparing to hand over to Beta

  1. Ensure the accessibility requirements are part of the handover. And handed over to the right people
  2. Train staff who will assist end users in disability awareness. Led by PwD. Nothing worse than seeking help to use a product, only to be spoken down to by someone who has no interest or understanding of disability!
  3. Test with a wide range of people. Then get dedicated feedback that allows for neg feedback as well as the positives

Onboarding and kick off of Beta

  1. Design team to agree on working tools and processes to ensure quality control. Accessibility tools, contrast checkers, pattern libraries etc.
  2. Define standards and guidelines the team will adhere to and prioritise.
  3. Ensure your team covers the requirements needed to create the accessible product.

Other considerations:

  • Try and break your website and app
  • Use accessibility tools during testing
  • Ask new users about assistive tech?

Build

  1. Use the latest technology and use up to date software: WP, Joomla etc. make sure you use the latest CSS standards, HTML and Javascript standards.
  2. Make sure to use accessibility tools for self-testing during development.
  3. Consider the benefit of templates (design systems, etc) to take care of multiple targets, better allowing you to focus on your specific needs.

Other considerations:

  • Follow the path of least resistance when providing information or links – ease of navigation.

Test

  1. Ensure testers know HOW to test for the required accessibility criteria
  2. Use accessibility checkers (as a first layer during development) and always get random people to test your software / app. So run auto-tests for efficiency, but never stop with them
  3. Test for understanding of content and instructions by people with learning or reading difficulties in addition to technical aspects

Other considerations:

  • Test with people with who are visual and hearing impaired and all other disabilities
  • Test using accessibility tools and devices.
  • Make sure your software system is up to date when testing

Go live

  1. Set-up ongoing feedback loops to assess the live product
  2. Continuous accessibility improvements
  3. External audit to verify compliance

Other considerations:

  • Check new and revised content as well as new features or functions
  • Continue to revisit with advisory groups, and adapt where necessary. But the adaptations need to not be unwieldy, for example the way the NDIS systems currently are
  • Celebrate the achievements with all stakeholders in the journey.
  • Take any feedback from users and use it to improve and update the product

1 thought on “Embedding Accessibility Earlier in Projects”

  1. Pingback: A year in review: 2023 – OZeWAI

Comments are closed.