Contents
Introduction
It is important that our design process not only considers accessibility in the outputs, but that the process itself encourages accessible design thinking, both within the design team and for the rest of the team who will implement our designs.
Project kick-off
This is where to set out your stall that accessibility is important to the design process. State that you want to have disabled users included in both the information gathering interviews as well as user testing throughout the project, not just at the end.
When in the discovery phase of a project and when hypotheses are being tested with users, efforts should be made to include the full range of users, including those with disabilities and other conditions. By doing this we can help expose any potential issues early on.
Read more about user research and accessibility
The later we leave testing with disabled users the more expensive in time and money it becomes to recitify any issues which we find.
For some projects it can sometimes be difficult to recruit any users who are invested in the task due to the narrow parameters involved. For example a government service for users who pay a particular tax may be troublesome to recruit any users for, let alone being able to find a disabled user who both matches the requirements and is willing to participate.
In these cases we can use a couple of approaches. We can loosen the recruitment parameters to request input from disabled users who are not necessarily the target audience. We can also use some user personas to help provide some insight. These are fictional users with specific conditions which we casn use to help inform design decisions throughout the process. GOV.UK has created seven sample personas which can be used as a starting point.
Content design
Content is at the core of an accessible and inclusive design so it is important that content and interaction designers work closely together. Content is not just about the copy used but how it is structured - for example using lists and headings to aid clarity. The content should inform the visual design.
Read more about accessible content design
Prototype stage
Designs should be tested at the earliest stage, even before any code is written. This can be done against a set of criteria, perhaps using personas and ideally with real users. Bear in mind users with access needs are just as varied as those without so personas can only take you so far. It can be useful to think in terms of supporting the tools the person needs to use. Read more about assistive technology.
When looking at designs, the simpler the interface the better. All users will benefit from less interaction. For example, do not rush to add an accordion to a page. Instead design the page with headings and paragraphs and test that with users. Only add complexity to a design where there is an evidenced user need for it.
You can test either a flat file (such as Figma) or an HTML prototype. At this stage it can be helpful to look at the different layers of accessibility on a page to help guide decision-making.
Flat file prototypes
With flat files we cannot easily test with people who use assistive technology like screen-reader users and speech-recognition users as these rely on code being communicated. But at this stage we should still be thinking about things which will affect those users, such as accessible names for any links and buttons and form controls. For example we can think about what a speech-recognition user might have to say to action a button and then ensure that text is visible on the button itself.
At this stage we can also think about:
- content structure such as heading hierachy to communicate semantic meaning
- keyboard navigation - how will a user move through the page; where will focus go; how will a keyboard user operate this component?
- colours - is contrast sufficient for text and UI elements?
- interaction - is affordance obvious; what would focus indicators look like?
- images - do we need alt text and what might it be?
- icons - do they need visible labels to help speech-recognition users?
- responsiveness - how will this design differ when seen on desktop vs mobile - will source order still match the visual? This can be important for keyboard and screen-reader users.
By testing here we can avoid the most costly of issues which is ones which require entire pages or even journeys to be reworked. In comparison to fixing design issues, accessibility issues which require pure code updates are simpler and less costly.
HTML prototypes
HTML prototypes are valuable because they allow pages to be designed and used in the actual medium they will be constructed in.
If you are using a design system as the basis for a prototype and it provides “macros” to save you having to write (or copy & paste) HTML for each component, then this is advisable. A macro will prevent inclusion of potential code errors into your prototype; make your prototype easier to understand; ensure you are not doing anything with the component the development team won't be able to do; allow you (or your successor) to more easily update your prototype to the latest version.
An HTML prototype will allow you to undertake some additional basic accessibility testing yourself, before putting it in front of any users.
- run an automated test tool like axe or Wave (you may need some help from a developer in understanding the results)
- test your prototype with a keyboard, can you see where your focus is, can you reach every button or link?
- how does it look on mobile or in landscape mode?
Done well an HTML prototype will mean you can even test it with screen-reader and speech-recognition users, which might not be otherwise possible until the first development versions of the site are available. For this reason it can be worthwhile pairing with a developer to improve the code quality of a prototype.
The importance of semantics
Where the visual design greatly affects the user experience for sighted users, the code we use to build the page does the same for those who use screen-readers and to a lesser extent speech-recognition.
A major part of this is using the correct element. Many HTML elements are semantic, which means that they carry a meaning which can be communicated to the user.
For example a piece of text might visually look like a heading by making it bigger than the surrounding text:
<p style="font-size: 32px; font-weight: bold;">Am I a heading?</p>
And whilst that might be enough for visual users, this will just be plain text for a screen-reader user.
The above code would be announced by a screen-reader as:
“Am I a heading?”
Whereas if we use an appropriate semantic element for that heading:
<h2 class="heading--large">Am I a heading?</h2>
Now the browser and screen-reader will work together to give the user a lot more information which will help the user understand the purpose of that content.
The new code would then be announced by a screen-reader as:
“Am I a heading? Heading, level 2”
So now the user knows that the text is intended to be a heading, and that it is a particular level of heading. The heading level will allow them to mentally construct a tree of content hierarchy in their head and start to understand how content on the page relates to each other.
Read more about the basics of building accessible sites.
This brings us neatly onto how we might communicate this important information to the rest of our team.
Development stage
Whilst you will likely be using an iterative design process, at some point designs will need to be prepped for use by the development team.
When a development ticket is raised we need to ensure any accessibility information we have gathered up to now is not lost. Some of this information could also be used by the testing team to write accessibility-focused test scripts which will help promote accessibility during the build.
Annotating prototypes
Even if a well-formed semantic HTML prototype has been constructed, a flat file visual with annotations can still be valuable to the development team as it will help remove any confusion.
When we have done a lot of work with our content and visuals to ensure they are well designed, it is important to not lose any of this when it is handed over to the development team. Whilst we should be working closely with them, it is helpful for all if the need for clarification about intent is kept to a minimum.
For some of this information it may be necessary to work with someone who has a good knowledge of accessibility and HTML. A little investment up-front can save a lot of back-and-forth or having to redo work later down the line.
Even if you are using a component library, telling the developers which component you are using can be a big help and as most components will allow for different options these should be indicated too.
We should not use this annotation as a complete replacement for collaboration. However it will mean that most points of clarity are covered, leaving time for collaboration on the more complex areas such as any new components you have created.
Think about the following for each page and how the information can best be communicated:
Basics
- how will this work on a small screen (such as a mobile) - remember that a large screen which is zoomed in will trigger a mobile view
- how will this work on a mobile in landscape mode
- are links obvious?
- does link text make it clear what the link is for?
- if a component is one you have designed new for this page, indicate this and provide as detailed a breakdown as possible (but closer collaboration on this will likely be needed)
- are there states which need to be communicated
Read more about the basics of building accessible sites
For form elements
- which text is the label and which is a hint
- what are the error messages which should be displayed
- should form inputs have autocomplete attributes
Read more about accessible forms
For keyboard users
- think about focus indicators and make sure they are clear enough
- are there places where we need to handle focus (for example with dialogs)
- what is the tab order when the user moves through the page
Read more about designing for keyboard
For screen-reader users
- what is the heading hierarchy on this page
- mark up which heading level each heading is at
- if a heading level requires particular css classes to match the visual, indicate what these are (otherwise the danger is that the developer will use the heading level size which matches the visual)
- if there are images indicate if they require alt text
- if there is any on-page interaction how is this going to be communicated to someone who cannot see the screen
- is there any hidden copy for screen-readers
Read more about designing for screen-readers
For speech recognition users
- are any icons easy to identify and will users label them in a consistent way?
- does the visual label for a control match the accessible name?
Read more about designing for speech recognition
For visual adjustments
- how is someone who is using a magnification tool going to know what happened when you update the page
- how will this component work if the text is made bigger - can the container grow to accomodate it?
Read more about designing for visual adaptations
Build review
Make sure that when pages are built that you review the finished product to check it has the accessibility features which you designed in. The development team should also be carrying out their own checks but it is important that everyone takes responsibility for the output.
Wrap-up
By considering accessibility throughout the design process and regular testing of designs produced an accessible solution is more likely. This will go a great way to preventing costly rework later on.