Accessibility Quick Wins for Your Mobile and Web Apps
Make accessibility part of your workflow
Software accessibility is a topic where you can invest hours, days, and even weeks of work, and on first glance, a user might not even recognize that. Maybe that’s a reason why accessibility is often an afterthought instead of being part of the regular development workflow.
Why do we need accessibility in websites or applications?
- By not focusing on accessibility, you lose lots of people that can’t use your website or app
- Some companies, especially large enterprises, have rather strict expectations when it comes to accessibility (which is a good thing)
- Writing accessible HTML helps you write better code — as it forces you to pay more attention to the structure of your HTML
Here are some essential tips on how to ensure accessibility in your app:
- Use semantic HTML elements as much as possible
- Use linting to catch issues early
- Write tests that check accessibility
- Make accessibility part of your development workflow
Let’s have a closer look into these aspects. In this piece, I want to focus on websites. The same principles for web accessibility can be applied to mobile apps on Android and iOS as the challenges and solutions on mobile platforms are quite similar.
Use Semantic HTML Elements As Much as Possible
There’s plenty of HTML tags available besides
span. HTML5 brought some additional semantic elements that don’t look any different than a regular
div. However, they’re more accessible since they convey some context. In addition, HTML5 provides us with some basic general-purpose elements that can be used to create forms, for example.
Here are a few selected rules you can follow when it comes to choosing the correct HTML element:
- If an element has a link to another webpage (whether it’s internal, external, or a route in a single-page application), it should be an
aelement. This ensures your links can be crawled for SEO and that they can be visited using both mouse and keyboard.
- If you need some kind of input field, you should use
textareafor multiline text). You can specify the
typeof the input (e.g. number), which not only helps for validation but makes your input more easy to use, especially for mobile users (i.e., by automatically showing numbers on a number input).
- If you need a clickable element, you should use a button in most cases. A button has stylings for different states (e.g.,
focus), and they can be used with both a mouse and a keyboard. Example: The popular CSS framework Bootstrap has plenty of button styles, including a link-styled button.
- If you want to show an image, you should use an
imgelement. This ensures your images can be crawled by search engines. You should further add the
altattribute. Screen readers read this description out to their users so they know what the image means.
- If you want to depict some kind of list, it’s a good idea to use a
olas a parent element and
lielements as direct children. The good old
tableis also a valid approach, but it can be harder to style with CSS.
- Elements like
i(which are often used for web fonts like FontAwesome) rarely need to be interactable directly — as there’s plenty of more accessible elements that are usually more suitable. If you do need them to be interactable directly, then you need to make sure they can be used with both mouse and keyboard (e.g., by using the
Let’s have a look at an example to see how semantic HTML can be way more readable.
Let’s look at a bad example first:
Multiple issues can be found in this code:
- Images without an
- The structure of the page is difficult to understand since most of the elements are just regular
- There’s list-like structures without using proper HTML tags, like
- The heading hierarchy is wrong
divinstead of more suitable elements like
pfor rendering large amount of text
- Using a
buttoninstead of an
atag to allow navigation to another page
Now let’s have a look how we can improve things when we try to write more semantic code:
- Images have
altattribute that can be read by screen readers
- The structure of the page is more clear — we have a header, a navigation area, two sections of content and a footer
- We use proper HTML tags for displaying lists
- The heading hierarchy is valid
- Using paragraphs to render large amounts of text
atags to show a link to another page
<user-single-select> is a good selector since it tells us developers what this component can do: allowing us to select a single user.
Use Linting and Other Tools to Catch Issues Early
There are several tools and libraries we can use to improve the accessibility of a website or an app. In general, these tools or libraries should be part of your regular development workflow to catch issues early.
- Static code-analysis tools, like HTMLHint, can scan your HTML for accessibility violations. These linters can be executed during development and on a CI server (e.g., Jenkins, GitLab CI) to notify developers when new code introduces accessibility issues.
- Some IDEs, like IntelliJ IDEA, have static code-analysis capabilities included, which can let you know of issues directly when writing code in your IDE. Additionally, there are a free IDE plugins/extensions, like Web Accessibility, which can help you to write better and more semantic code.
- It’s possible to run these checks or audit tools automatically before committing your changes using Git hooks. This way, you can fix the issues these tools detect right away instead of waiting for a CI job or another developer to check this.
- There are some audit tools and web services, like Lighthouse (built into Chrome), which can run accessibility checks in your browser and on a CI server
- A great tool that’s not actively used isn’t useful at all, so you should make proper use of the tools you have
Some accessibility linting rules I recommend using:
- Check if a
labelcomponent is associated with a form element (like
- Check whether image elements have alternative text
- Check whether elements with events such as
clickcan also be interacted with using a keyboard
- Check whether the HTML structure is valid (e.g., an
h2element shouldn’t appear before an
lishouldn’t be a direct child element of a
Make Accessibility Part of Your Development Workflow
You’ll make you and your coworkers’ lives easier by making accessibility not an afterthought. Instead, you should aim to make accessibility a part of your development workflow.
Let’s say your product (e.g., a web app) has existed for a few years now. Until now. you and other developers didn’t really care for accessibility. Product management comes to you and says, “We have to do accessibility now to satisfy some of our clients that demand this.”
Usually, there are two approaches when it comes to change management:
- Big-bang approach: Invest a lot of time and resources to make your app accessible
- Incremental approach: When writing new code or improving existing code, make sure to incorporate accessibility
Obviously, the incremental approach scales far better and is preferred, in my opinion. It’s also easier to pitch this approach to product management than the big-bang approach. However, you might need to help product management understand the relevance of software accessibility.
Make Accessibility a Feature of Your Product
The product team, which includes both engineering and product management, needs to incorporate accessibility as a feature of your product(s). It’s often not enough if only one side is fighting for accessibility.
- If product management doesn’t fight for accessibility: Developers won’t do it since they can’t justify putting this effort into something that product management doesn’t prioritize
- If engineering doesn’t fight for accessibility: The product will grow and become more difficult to maintain. The later accessibility needs to be incorporated into the product(s), the harder it’ll be to do so. Since not every company is incorporating accessibility enough, there may be some learning curve for some developers.
Thanks for reading this short piece about achieving quick wins in software accessibility. There’s a lot to talk about with this topic. How do you approach accessibility in your software products?