Web Accessibility - Clickable Objects and Screen Readers

in accessibility •  5 months ago

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!

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

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

·

I've been considering opening an issue at Busy's GitHub. Or maybe I could report the problem through Utopian? I've read that Utopian is really strict and has very high standards, and I still haven't managed to gather the courage to try it out yet :P . Before reporting the problem to Busy, maybe I should try to find the fix for it too.

While we are at it, where is Busy's upvote button? Is it below the post? From the HTML I looked at, I noticed some things that seem to be icons and thought the upvote button might be in there, but I'm not sure. Is there a downvote button too? I couldn't find it. And Busy seems to have a feature to bookmark posts (at least it has a bookmarks section in the menu), but I still couldn't find an option to bookmark posts anywhere. I wonder if this is also hidden behind an icon.

·
·

Yes. Busy shows the upvote button after the post body. They use a hand instead, like Facebook does.

Downvote is located in a menu. But as text, not as an icon. Before opening the post, that menu is shown as three dots near the upvote button and rewards and comments count. When the post is opened, the same menu is shown near the post title. The bookmark is also included in that pop up menu.

On the github topic. There is no need to wait until having the fix for it.

Posted using Partiko Android

·
·
·

Thank you for the explanation!

I hadn't known about that popup menu with downvote and bookmark. My screen reader can't find it at all, and Firefox's HTML inspector also gives me no clues. It sounds like these issues may be even worse than I had thought...

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.

·

Agreed. And those screenshots are frustrating! Especially when people post tutorials and don't explain anything with text. For example, instead of saying, "Go to 'Edit' > 'Preferences' and enable the XYZ option" they just say, "Do it like this:" and post a screenshot "And you'll get this:" and another screenshot. Having both the screenshot and a basic outline of the steps as text would be ideal. A picture is worth a thousand words to those who can see it, but those who can't need at least a few words.

·
·

Video references too ... I'm able to both see the video stream and hear the audio stream, but I still usually don't play videos for several reasons.

Some few times I also feel I've wasted fifteen minutes of my life watching something that could easily have been covered by five sentences of text.

Having those five lines of text in the post in addition to the video link is just perfect, I can skip watching the video.

·
·
·

Ugh, this reminded me of those video tutorials about... programming! Without any textual explanation or sample code... I bet even some sighted people have a problem with those.