An accessibility-first design approach
An accessibility-first approach needn’t be radically different from existing design strategies you’re familiar with
Working as teams or individuals, we often talk about accessibility in the design process as one of numerous requirements to be prioritised. The keyword to be concerned about here is ‘prioritised’. One person’s critical tasks may be another person’s minor tasks for the backlog.
In this blog post I’ll be exploring an approach that puts tasks relating to accessibility first at each stage of planning and creating digital products, primarily websites, while taking into consideration some existing, more widely known design strategies to support this approach.
A little about me
I joined dxw as a web developer in early 2020 and in the summer of 2021, I became certified by the International Association of Accessibility Professionals (IAAP) as a Web Accessibility Specialist (WAS).
Before working at dxw, I often worked in roles applying my specialism in frontend development to code accessible interfaces. This role has regularly involved metaphorically sitting between designers and backend developers to collaborate with and help foresee or identify existing weak points and potential flaws on both sides of the production process.
Now in my current role as developer on the GovPress team at dxw, I spend my time writing code and reviewing code from others on my team, as well as auditing and improving websites for better accessibility. Alongside client work, I run the dxw Accessibility Forum and accessibility related workshops internally to help improve knowledge and awareness of accessibility throughout dxw.
Design strategies – an overview
Over the history of digital product design, we’ve seen the emergence of quite a few best practice approaches which justify that one approach of setting a specific baseline requirement to start from is best for most, if not all, projects.
Flexible web design
In 2008 Zoe Gillenwater published a book called Flexible Web Design. This itself wasn’t, strictly speaking, adopted as an overall design strategy, but it helped start a conversation among the web community on more flexible, robust web design approaches in the years ahead. Zoe discusses the benefits of flexible layouts and choosing between a liquid, elastic, or hybrid design. All of this was little more than a few months since the first iPhone had launched and the range of screen sizes still remained relatively small.
Mobile-first
This approach came about in 2011 with the publication of a book “Mobile First” by Luke Wroblewski, that’s now free to read. The mobile-first strategy arrived just around the same time that mobile internet usage was exploding. Mobile-first was interpreted by many companies as a separated design approach with a website design for mobile that’s different from their existing website designed for desktop.
This design approach remains prevalent on the web, but it often offers a much poorer user experience if not implemented well. This might be because not all the content or features of the website are made available to users accessing the mobile version of the website.
Responsive web design (RWD)
RWD is an approach for designing to adapt to the available space of a browser’s viewport width, instead of the earlier approach of designing for a small selection of fixed width viewports.
Many people now access the internet solely with their phones or tablets, which is why the RWD approach remains a highly relevant and important part of a comprehensive design strategy.
Content-first
In 2008 Jeffrey Zeldman first coined the content-first approach where content is part of the design process before anything else. It is often considered an appropriate approach to apply for clients and teams focused on user engagement as the highest priority. Ahead of thinking about what layout style, web technologies and architecture to use, the intention of a content-first approach is to first decide what the is content going to be. Ideally anything that may be considered content from plain copy to multimedia, an idea or story to tell needs to be gathered at a content planning phase initially.
In this approach, RWD/mobile-first is also very relevant and necessary to be considered as a secondary phase to follow on from deciding what content we have to work with.
Progressive enhancement
Strictly speaking, this is a development strategy but progressive enhancement may often be considered a baseline to help guide both the design and development process.
As my colleague George recently put it in his blog post, progressive enhancement is why we build things from the ground up:
a design principle by which you write your software in the least powerful language, rather than the most powerful
Why accessibility-first?
An accessibility-first approach needn’t be radically different from existing design strategies you’re likely familiar with already. Having empathy for disabilities and being aware of what a disability encompasses, beyond the most common preconceptions, is an important first step.
1. Start with a solid foundation of accessible interface design
Creating accessible interfaces that serve a wide range of user needs and functional purposes can be hard work without knowing frontend technologies will be backed up by extensive testing for usability as well as code-based testing. For example, accessibility, continuous integration, and unit testing.
Short of having ample time, people, and budget to do all of this really well, you’ll need to find an existing example of extensively tested design styles, components, and patterns. We incorporate the GOV.UK Design System into many of our projects and have recently started work on our own extension to this design system called dxw Frontend.
When there’s a need to create bespoke interactive features which don’t already exist, we refer to resources such as Inclusive Components to help guide our development process to design and code components that are accessible to as many users as possible.
2. Identify fragility in a design and codebase that impacts accessibility early
Applying an accessibility-first approach throughout the process of designing and coding an interface depends on knowing if you’ve done something that impacts accessibility and prevents or excludes some users. Find an approach in your team that stops things progressing too far before it’s too late or costly to undo mistakes that impact on accessibility. Get everyone to understand at what point a design or piece of code becomes less accessible and why.
To some extent, knowing when something impacts on accessibility comes down to months and years of experience in seeing where and how previous websites failed accessibility tests and audits. Additionally, having a good awareness of using assistive technologies and how different users access the web when they have a disability are also very valuable to help make informed decisions about how an interface should be designed and coded.
At dxw, working to an agile methodology means we can validate individual features of a project prior to release with greater efficiency and scrutiny over aspects such as code quality and overall accessibility.
3. Test and validate accessible design
An accessibility-first approach can’t be relied on as a guarantee to good accessibility for how a product is finished and delivered without a solid plan for testing and validating during and after the work is done.
Many of our team use Figma software for creating designs, which also has a plugin from Stark that adds a suite of integrated accessibility tools to help design with a focus on accessibility. This helps with checking for colour contrast issues, focus order and sequences.
Finding the best time to test is important. You don’t want to be testing half-finished work, but at the same time it’s good to identify problems early on before they’re deployed all in one go. This is where having in-house accessibility specialists can help design and build teams to work more efficiently, compared to outsourced accessibility testing that’s often only feasible after designs have been signed-off, built, and deployed.
Usability testing is also something to be considered early on in validating your design for accessibility. Depending on what and who your product is for, then you might already have a range of participants with disabilities available to provide valuable feedback on your designs and test built features. Otherwise, consider companies such as Fable who can help connect you to people with disabilities for user research and accessibility testing.
4. Maintain a long term accessibility-first approach
An accessibility-first approach isn’t just about considering an accessible design approach, but a long term plan for how a digital product remains accessible for months and years to come.
If your organisation uses a content management system (CMS), such as WordPress, then make sure you’re using tools to assist in making accessible content. A CMS should adhere to the Authoring Tools Accessibility Guidelines (ATAG) so that the authoring tool is itself accessible and helps authors produce accessible content. If your users are publishing their own content, then it’s important they can make it accessible before it’s made public.
Accessibility knowledge and practical application can and should be a requisite for many job roles in web design and development. It sadly isn’t taught in most schools and universities to the level or extent it needs to be. Consequently, you should look for gaps in accessibility knowledge across your team and schedule in workshops or training, so everyone can get more experienced in testing and identifying problems early on that may impact on accessibility.
Reserve an hour or 2 each month or week in your organisation to give your team time to learn and share knowledge on accessibility.
5. Decide an approach that’s as accessible to as many as possible
An accessibility first approach for your design strategy can at first be a challenging way to think about how you prioritise features and decisions about a project. They might be more easily understood and justified by asking who do we exclude by taking this approach?
Ultimately, it may be a matter of deciding how much inaccessibility in a product or feature will cost you in the long term. Discussing the things that will impact accessibility-first rather than last is more than likely easier than the other way round.