Recently, in the position of a frontend developer, I was invited to a Q&A session by a UX design team of a large company in Vienna, where the goal was to find out together where the responsibility for accessibility in the web development process lies.
I will share the questions I was asked during the session by the UX team and my answers transcribed. I hope to give you a sense of how to implement accessibility into the web development process from a frontend developer's perspective.
Table of contents
- At what stage should we share the a11y guidelines / requirements?
- What can you do as a designer to make sure the developers know how to build it?
- What do the developers need in the briefing regarding accessibility
- Make functionality available from a keyboard: Where does the reading flow begin?
- Show where your focus is: How to display hover state on keyboard?
- How to communicate with developers?
- A11y for frontend developers
- Conclusion
The session started with an introduction about what accessibility is and how it is implied in UX design by the UX team of the company to give the developers of the project an insight about the topic.
1. At what stage should we share the a11y guidelines / requirements?
It is very good practice to have accessibility guidelines not only for a specific project but generally within the company itself. These should be shared with all employees already when they are hired, so that everyone is aware of these guidelines.
2. What can you do as a designer to make sure the developers know how to build it? (Set constraints in Figma)
Will be answered together with question 3.
3. What do the developers need in the briefing regarding accessibility? Should this be in the Figma file as a comment or a post-it?
I would like to answer these 2 questions together:
There is a difference depending on the size of the company. If there is no dedicated UX Designer, there the frontend developer often does the UI design and development, ergo they are also responsible for a11y.
In case of a team where there are both UX designer and frontend Developer, I see the split as follows:
If I as a dev get a design that I now have to convert into code, I don't want/shouldn't have to worry about whether the color contrast is high enough, about the font size and family and the button are big enough, or whether the position of the popup makes sense.
...Text should be left or right aligned, no longer than 80 characters (font 80ch), letter spacing and l*ine height.. . These are things that **should be decided at the design stage* with a11y in mind, so the UX team should take this into account, that everything meets the a11y criteria.
The implementation of the design, to make the code fully a11y now, is up to the dev. There is no reason, when it comes to code, that a UX designer would still have to get involved here in a big way.
Anyone who deals with frontend and cares about staying up2date should have some basic understanding of accessibility anyway, e.g. semantic HTML etc. After all, this is my job as frontend developer.
It starts simple: Semantic HTML is just the minimum that every dev has to know and understand anyway, that's why they are frontend devs. There are more than 100 HTML tags, and most of them already make a component accessible.
So when I get a design, I know what the header is, the main content, the footer, the navigation. Accordingly, I write these components using the intended semantic HTML tags.
Common bad practices or incorrect use of tags in relation to a11y can often be found in:
e.g. button and links. There are differences between button and a tags:
Do not nest interactive elements. If you need a link that looks like a button, design the link accordingly. A click event on a graphic fires only when clicked. A click event on a button fires when it is clicked and when the user presses the Enter or Space key. ..cursor pointer automatic on link.
JavaScript void on a tag means that it is not a link!
Every img tag needs beside height and width also an alt attribute, even if it is empty (in case of a decoration image. Best would be to insert these sort of images with CSS as background).
When there is no text alternative for the image, screen readers may will announce the file name or the image URL.
When writing letters in uppercase, screen reader may read each letter out loud (like USA), so write the word in lowercase and style it uppercase with CSS.
Do not set the user scalability to "no". People with limited vision need to zoom them. If the design doesn't work, the problem is in the design itself.
4. Make functionality available from a keyboard: Where does the reading flow begin? Does it go from H1 to h2, or top to bottom, or component?
Everything is basically correct here. The reading flow starts as the DOM order is written, so it is important to use semantic HTML and not interrupt this flow e.g. by tabindex, or other CSS attributes.
A page should best be divided into landmarks that can be easily displayed with semantic HTML: header, navigation bar, main content, side content, sections in the main content, footer.
The user can then navigate between these landmarks with the help of a screen reader. The next selection is the headings, which must appear in the correct order. There can only ever be one h1 per page, as this is effectively the title of the page, and there is only ever one title. An h1 can never be followed by an h3.
This is also purely HTML and not styling. It is perfectly okay that e.g. on your page here, the title looks exactly like the first h2 heading, if it is your branding, as long as it is marked in the DOM as different headings.
This is important for people with visual impairment who use a screen reader, they want to know 1. what page it is (h1) and then what the first section contains (h2). They don't care about the styling.
5. Show where your focus is: How to display hover state on keyboard? Can keyboard-only users hover?
There are always problems with the hover effect and it should therefore be used with caution and certainly not to display important content. An equivalent to hover for keyboard users would be focus.
6. How to communicate with developers?
It happened to me only once that I had questions about the design and that was in relation to stages of responsiveness of the design from desktop to tablet. But I didn't get a useful answer from the UX designer (who was still a junior themselves), so I decided on my own how to do it. No one complained, so it will have been fine 😅.
From the current perspective, now that a few months have passed since the QA, my answer would be that communication is dependent on the design system. If the system is prepared to provide explanations for each component, the system should speak for itself.
In case of questions from the developers, there should always be a contact person in the UX team who can give information about ideas of the functionality of the project.
Design tools such as Figma are so mature that you can recreate almost any interaction and send it to the developers.
Good and respectful communication is always key in a team.
7. A11y for frontend developers
At the end of the QA session, I shared what I thought were the most important points for the frontend development team to focus on and shared useful links and tools for them to work with to get used to accessibility in the process.
Get an understanding of
- semantic HTML
- focus, focus-within, focus-visible
- interactive elements like buttons, links and forms
- reading order / DOM order
Important links and tools
- W3C ARIA Authoring Practices Guide
- WAI Tutorial Tutorials
- Markup Validation The W3C Markup Validation Service
- Axe DevTools
- Wave
- Taba11y
- NVDA, Jaws, Voice Over
8. Conclusion
I enjoyed the QA session very much. It was exciting to talk with a team full of UX designers about accessibility in the web development process, share views and took a lot (also new) from the conversation.
Thanks for your reading and time. I really appreciate it!
Top comments (2)
Congratulations for this post, I can only say that everyone who is involved in the creation of online contents, from members of the development team to the writers, is responsible for accessibility.
Each one of them should know the basis of digital accessibility, and care about it.
One of the prime reason for inaccessible contents, as many accessibility experts say, is ableism.
Disabled people are everywhere and deserve the same rights as non-disabled people, including access to online contents.
There are a full spectrum of disabilities who affects the way people access to online contents.
Everyone accesses the web in its own way, and everyone could be disabled in a way or another temporarily or definitively.
Thank you for your insights on this, Francois.