Accessibility Quick Wins for Your Mobile and Web Apps

Make accessibility part of your workflow

Ali Kamalizade
Feb 4 · 7 min read
Image by Jil Wright on Flickr

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

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 a element. 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 input (or textarea for multiline text). You can specify the type of 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., hover, 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 img element. This ensures your images can be crawled by search engines. You should further add the alt attribute. 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 ul or ol as a parent element and li elements as direct children. The good old table is also a valid approach, but it can be harder to style with CSS.
  • Elements like span, div, or 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 tabindex attribute).
  • Some use cases might require the use of JavaScript. JavaScript can help us to ensure accessibility for dynamic content. For example: Custom tooltips (see here for an example) often need JavaScript in order to work.

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 alt attribute
  • The structure of the page is difficult to understand since most of the elements are just regular div elements
  • There’s list-like structures without using proper HTML tags, like ul
  • The heading hierarchy is wrong
  • Using div instead of more suitable elements like p for rendering large amount of text
  • Using a button instead of an a tag 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 alt attribute 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
  • Using a tags to show a link to another page

The following is advice more for your fellow developers than the actual users of your website: You should also name components as clear as possible. When creating a component (e.g., using Web Components or a JavaScript framework, like Angular or React), you need to specify the selector for this component. <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

  • 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
The Web Accessibility extension for Visual Studio Code highlights accessibility issues

Some accessibility linting rules I recommend using:

  • Check if a label component is associated with a form element (like input and select)
  • Check whether image elements have alternative text
  • Check whether elements with events such as click can also be interacted with using a keyboard
  • Check whether the HTML structure is valid (e.g., an h2 element shouldn’t appear before an h1, a li shouldn’t be a direct child element of a div element, etc.)

Make Accessibility 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

  • 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.

Conclusion

Better Programming

Advice for programmers.

Thanks to Zack Shapiro

Ali Kamalizade

Written by

Software Engineer @leanix_net. Co-founder of Sedeo with a passion for software engineering, SaaS and startups. I write about topics I’m interested in 🚀

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade