This is my live keynote talk at the @DrupalConNA 2021 conference on 15th April 2021. I presented a case study of how we delivered an accessible website for SportEngland. Transcript below.
Enjoy, subscribe, share with your colleagues and get in touch if you want to know more ;-)
Welcome again, everyone. Thanks for joining this talk. Today we'll speak about, why you need to consider accessibility throughout the project life cycle. We'll do that using a case study from one of our clients.
Accessibility is not yet the norm
But first of all, I want you to imagine having to blindfold yourself, grabbing your phone and trying to feel a very important application form that will allow you to get funding for your sports club and ensure it survives during the pandemic for example... how is that going to go for you?
I can you imagine you'll be giving up before you can even enter your name on the phone, right?
It's really important that we always think about how blind users can enjoy the same convenience as we have on the internet. Everything is a few taps away for us, but often we forget about people with accessibility needs.
When we build a website, it's the norm nowadays to make everything responsive for large desktop and narrow phone devices... It comes as standard. But it's still very far from being the norm when it comes to accessibility.
It's even a legal requirement now with Section 508 in the US or similar regulations in Europe. Even if you avoid any fines, you need to think about the reputation of potentially losing government contract and credibility through some bad PR.
SportEngland's case study
In the next 10 minutes, I'll share with you the exact steps and all our secrets on how we delivered an accessible website for one of our clients: SportEngland.
SportEngland's mission is to keep the UK population active. A big part of their remit is to support disabled users and funding clubs that promote physical activity.
If you follow all the steps that I'll show, you will have a website that is not only accessible and compliant, it will also help your search engine optimisation, the performance and the overall user experience for everyone.
The results for SportEngland have been amazing and we'll see, in a few minutes how we did it.
As a quick background and introduction, I'm Sylvain Reiter, the co-founder at Cyber-Duck. We are a digital agency based in London in the UK. We're delivering digital transformation through user-centered design, UX, and technology. Of course, we do all of that, mostly using Drupal!
How to get started
So how do you get started on your next project? Well, it's not just an item on your launch checklists. We all often say in the community, that whatever you need to be done, there's usually a ready-made Drupal module for that! "In the open-source community, someone's done it".
That's not the case here. There's no shortcut. It's not a last-minute fix that you can do during final UAT stages. It really needs to go on throughout the project life cycle.
So let's explore each one now.
Accessibility during the User Experience phase
We'll start from the user experience phase. That's very early in the project, when you start identifying the audience. You have to make sure you include all users with specific access needs in all research stages. Think about not only their needs, but also their goals and ensure they have a specific access... that all of that is factored into the persona and the user research you do. This is by thinking about how dyslexic users or visually impaired users could be interacting with your product and services.
From there, you can plan a clear navigation at the information architecture stage. In term of how you're going to group the content together and how you're going to section different headings... just to make sure that your users can easily find the content that they are looking for.
Then you need to think about the content and make the content accessible in multiple formats. In this example, on the website that we built, obviously the default is HTML. But anytime there is video content, we enabled captions or provided a version in large print. With the PDF, there's a big debate at the moment where they can be made very compliant, but are usually less accessible when they have complex layouts. You need to think about all of that and not just configuring your CMS for HTML, but for other formats as well, and make that accessible.
When you start populating the pages in the CMS, you need to make sure you define a clear structure with headings that make sense. I'm not sure if you've ever seen how a blind user is using a site? This is how they navigate.
Do you see how the assistive technology is reading out loud the different headings of the page? That's why they need to be very descriptive, so the user knows which one to click on and where to stop, to go to the right section of what they're interested in.
The final stage is also thinking about interactive forms, which is usually the main call to action or the main goal when you're building an interactive website. You need to make sure that you have the right labels, clear errors and validation messages. Everything is to follow the standards to make them accessible.
Visual design and accessible colours
We can then move on to the visual design stage. One of the most common accessibility need is around, colour and vision. Colour blindness and visual impairment, either due to age or other diseases.
What we find most often is a challenge with corporate brand guidelines, is when clients come to us with specific logos and colour requirements, but those guidelines are often outdated, they were not made for the web and completely not accessible. We need to have that flexibility and make it clear to the client early on that we're going to have to address them.
In term of the colour contrasts, aim as a minimum of 4.5:1 in term of the ratio, think about the font sizes, the background colours... There are a few tools that you can use like this plugin, it's called Stark and that's accessible to Sketch and Figma. Share that with your design team, they should be aware of that. And again, make sure you have the design right before you start coding.
Accessible web development
We can then move on to the coding stage. Obviously, the code that you write is what's going to be rendered and read by assistive technologies such as a screen reader. You need to pay a lot of attention to the different tags for the different headings, having ALT tags on all the images and the right captions, the right aria labels...
The specification and the guidance from the WCAG are very specific, that's where you need to spend, in term of slicing a design, a little bit of extra time if you want to make it very compliant. You need to plan that early on in your budget and your timeline as well.
Another point to highlight is the order of the elements to enable keyboard navigation. You can see on the SportEngland's website, there is a secondary navigation on the top right. And even though it appears above the main navigation, it should be secondary in term of the tab order, when users are navigating. You want them to go through the main navigation. Do you see this "Go back to top" button in the footer of the page? When that's being clicked, you need to reset the tab order to start again from the logo in the main navigation. See how it interacts with the search and all of that? There's a lot of little details that are completely hidden. Clients don't usually see the little details, but it does require extra time & budget to positively impact accessibility for your end-users.
As you've seen again in term of design, coding, there's no shortcut and there's no Drupal module for this! You have to do the hard work.
Validating accessibility with the pros
Now, once you've built your website, it's time to test what you have done. But it's really hard to test your own work. And a lot of the automated tools never really cover the whole accessibility requirements, they're mostly not suitable.
You see on this website, it's very easy to get a 100% on the Google Lighthouse score, but it's not very accurate!
What we had to do is get real users, we're bringing external partners that are performing tests, with disabled users using real assistive technology devices... like it would be in the real world! Those automated tools cannot cover that.
If you don't have the budget, there are some other plugins and tools that you can simulate assistive technologies like JAWS and NVDA, you can try to do that. If not, you can also bring an accessibility partner, an agency like us. We're a member of the International Association of Accessibility Professionals, and we can do some additional audits and give you some reports about the different level of compliance.
Accessibility for ever!
You don't need a full external retest on every deployment, but try at least to use some of those automated tools to validate the key items on every release. You can put in some things to automate as well in your continuous delivery pipeline.
I hope you found this useful. We can stay in touch, feel free to connect with me to continue the discussion on Twitter or LinkedIn. We are also recruiting at Cyber-Duck: Drupal developers, Technical Leads and UX Designers as well, so feel free to get in touch.
It's your turn to be the hero
To conclude, I just want you to remember who we are building websites for? It's very important that you always think about the end-users and the customers, ALL our customers.
I want you to try and be the HERO of your next project and make sure you don't leave anyone out. Because everyone deserves a great experience when they come on your website.
If you need any support with accessibility for your next website or a SaaS product, just get in touch. Don't forget to subscribe to my YouTube channel and follow me on Twitter to keep learning with me and grow your career in digital.
Until next time, stay safe and see you soon.
Extract of the slides: