scrobble.life
#accessibility

Web Accessibility - Clickable Objects and Screen Readers

To me, a visually impaired person who uses the computer only through the keyboard and with help of screen reader software, one of the things that most hinders my Internet-browsing is the abundance of inaccessible clickable objects. Those elements with the "onclick" attribute which triggers a Javascript function when the elements are clicked with the mouse. In my previous post, I mentioned how I'm having trouble navigating the Steem Monsters website, and it's exactly this "clickable objects" case. In fact, this issue is very common, and many other sites have this problem. It happens even at some places on Steemit itself, and in Busy there are even worse objects (I can't even tell where the upvote button is!). Anyway...

An image of a mouse and a keyboard
Image source: Openclipart

The Problem

Usually, to navigate through pages with a screen reader, the arrows scroll through the text, and elements for interacting with the site such as links, form fields and buttons are focused with the "Tab" key and activated with "Enter" (and also the spacebar in the case of buttons and checkboxes). When sites only have normal buttons and links, everything works fine. But when they start using spans or divs with images and onclick with Javascript to create "buttons" with custom looks, that's where the headaches start. These objects can't be focused with "Tab" nor activated with "Enter." They usually only activate with mouse clicks, and there is no way for screen readers to know that these objects are buttons. Some screen readers may even include features to do some workarounds by trying to identify objects with "onclick" and simulating a mouse click on them, but it doesn't always work.

The solution

Thanks to the ARIA (Accessible Rich Internet Applications) attributes, site developers can set HTML elements to "tell" screen reader programs that the elements should be interpreted as links or buttons. On the developer resources page at Mozilla (MDN), there is a very simple to understand explanation about what ARIA is.

In fact, the solution isn't hard, unless the developer has gone crazy with Javascript and unusual HTML elements. For normal cases, whenever possible, it's best to use "true" HTML links and buttons ('a href="#",' 'button,' 'input type="button",' 'input type="submit"' etc.), because they are accessible through the keyboard by default. But if for some reason it's not possible and you're forced to use divs or spans or whatever else, the way to go is:

  • Add 'tabindex="0"' to make the object focusable by the "Tab" key.
  • Add 'role="link"' or 'role="button"' to tell screen readers that the object should be interpreted as a link or as a button.
  • Add Javascript to make the objects behave like native links or buttons, and that in addition to mouse clicks, they also respond to pressing the "Enter" key (event.keyCode 13) for elements with 'role="link"' and additionally the spacebar (event.keyCode 32) for 'role="button."'
  • And if the object is an icon with purely visual identification, it must have a textual identification for screen readers. This can be resolved with the 'aria-label' attribute.

Brief Examples

Here are basic examples of spans with 'role="link"' and 'role="button"', with 'tabindex="0"' and Javascript to detect "Enter" and spacebar keypresses, where "function_to_trigger" is the function to execute when the object is activated.

A span disguised as a link, which activates with "Enter:"

<span tabindex="0" role="link" onclick="function_to_trigger();" onkeydown="if(event.keyCode==13){function_to_trigger()}">A span disguised as a link</span>

A span disguised as a button, which activates both with "Enter" and spacebar:

<span tabindex="0" role="button" onclick="function_to_trigger();" onkeydown="if(event.keyCode==13 || event.keyCode==32){function_to_trigger()}">A span disguised as a button</span>

Below are some links I found, with more detailed explanations about how to create accessible custom buttons, with tips and examples.

This last link doesn't talk about clickable objects specifically, but it's very common to find clickable icons using Font Awesome with no textual identification, completely invisible to screen readers.

These were only the basics. As with everything in life, it can become way more complex (the case of sites going crazy with Javascript and custom elements). But I think even the most basic accessibility implementation for clickable objects would make the lives of screen reader users much easier! I hope this post can help create at least a few accessible clickables.


This post is participating in @qurator's Toss Up Thursday contest, whose prize is a month of bigger upvotes. If you are also a member of @qurator, and if you liked my post and would like to support me, please upvote the comment with my entry (only upvotes from Qurator members count). The vote value doesn't matter (it can even be a minimal 1% upvote as long as it's from a Qurator member). Thank you!

Comments · 2

  • @tobixen(63)· 3001d

    I have a belief that a focus on accessibility often will be a net benefit for society as such. For one thing, web sites designed to be universally accessible will often render better across different platforms and devices (not much of a problem today - but I consider the late 90s and early 2000s as the "dark age" of the web, "impressive" web sites were built, but they were only "impressive" as they were demonstrated on computers with the right screen resolution, a LAN-connection to the server, some exact version of Microsoft Internet Explorer, etc - viewed on any other platform or with low bandwidth, they would fail).

    On Steem there is a tendency to post screenshots whenever one wants to represent text from some other web site or application. This is bad, bad, bad - even though OCR software exists, I guess those screenshots can't be read by people like @aiyumi. It also can't be collected by search engines, it may be unreadable from some mobile browsers, etc, etc.

  • @javirid(56)· 3001d

    Great post. You wrote not just about the problem, but also about the possible fix of it.

    I think most websites are designed for people with full visual capabilities. Then, some day, someone arrives to the office and watches a video about accessibility and the convinces their designers that something must be done on their site.

    Let's hope someone do something on it on Busy. Meanwhile, they are an open source project; may I suggest you to open a issue on their GitHub repository?

    Posted using Partiko Android