Suggestions to Make Busy.org Accessible to Screen Readers

Repository

https://github.com/busyorg/busy

Components

Busy.org is a social network website that rewards users for posting and voting on other users' content. It is a front end to the STEEM blockchain, similar to Steemit, but has other features not present on Steemit, such as displaying how much voting power the user currently has, showing how much the users' upvotes are worth, displaying a slider for any user to control how much voting weight to use (unlike Steemit where only users with at least 500 SP have access to the slider), and an activity page showing everything each user did. However, the Busy.org site is currently not very friendly to screen readers and keyboard-only users.

The Problem

Screen readers are software that report to the user all the text displayed on the screen, typically either by reading the text aloud using text-to-speech technology, or by presenting it in a tactile form through a Braille device. Screen readers are commonly used by people with visual impairments to interact with a computer. In order to be accessible to screen readers, web applications should ideally provide means for the user to access all their features from the keyboard in addition to the mouse, and provide screen readers with textual identification of interactable objects (E.G. buttons) when the objects do not have text of their own.

The Busy.org interface currently has many icons that have no textual identification, cannot be focused or triggered by the keyboard, and are inaccessible to screen reader users (who generally are keyboard-only users). For mouse users, descriptive tooltips appear when the mouse cursor hovers over most of the icons, but these custom tooltips are programmed in a way that makes them inaccessible to screen readers as well. These problems make screen reader users unable to access essential site features such as upvoting and reblogging content, and heavily hinder their user experience. The inaccessible items include the icons to upvote ("Like") content, to reblog content, to open a menu with extra options and the options themselves, as well as the buttons in the Markdown editor.

Below is a screenshot of an own post's footer, where the aforementioned icons (minus the "Reblog" icon) and comment Markdown editor buttons appear, showing the (also inaccessible) menu with the "Edit post," "Save post" and "Flag post" extra options that appears when the icon with three dots is clicked with a mouse:

Below is a screenshot of the footer of a random post by another person (arbitrarily chosen for illustrative purposes only, linked to give credit), where the "Reblog" icon appears alongside the other icons, unlike in the own post:

Most of these icons are either links ('a' elements) whose lack of a 'href' attribute makes them inaccessible from the keyboard, or clickable text in 'span' or 'i' elements which only mouse clicks can trigger.

Other inaccessible buttons include:

• The "Confirm" and "Cancel" buttons on the dialog that appears when the "Like" icon receives a mouse click.
• The buttons to edit and to reply to a comment.
• The "Discussions," "Comments," "Followers" and other items in the menu on the user profile pages.

Proposal Description

Below are suggestions of ways to make the icon buttons readable by screen readers and interactable from the keyboard:

For the link elements and other clickable text

As long as links ('a' elements) have a 'href' attribute, the "Tab" key will give them focus and the "Enter" key will activate their 'onclick' handlers by default. Thus, the easiest way to make most of these clickable objects respond to keyboard input without the need for additional Javascript would be to wrap the spans and other clickable text into 'a' elements, then treat them alongside the other objects that are already 'a' elements as follows:

• Add a 'href="#"' attribute. This will make the objects respond to keyboard input.
• Add 'aria-hidden="true"' to the icons (the 'i' elements inside the links) to hide them from screen readers and avoid other problems.
• For the links that only have icons and no text but have custom tooltips, the ideal solution would be to use the 'aria-describedby' attribute with the ID of the element where the tooltip's text is written, or if not possible, an alternative could be to add the 'aria-label' attribute with the same text as the tooltip (text in an aria-label does not display on the page visually and is only meant to be read by screen reader software).

For the buttons in the Markdown editor

These buttons already respond to keyboard input, and only need text for screen readers to identify them. Adding 'aria-hidden="true"' to the icon and either an 'aria-describedby' attribute with the ID of the element that has the tooltip's text, or if not possible, an 'aria-label' with the same text as the tooltip (as mentioned before).

Code Examples

Since these are non-visual changes, there are no screenshots, but just mockup code snippets.

Below are a few examples of how the rendered HTML code for the buttons might look like after applying the above changes, based on edited output from Firefox's HTML inspector, and using the same text from the tooltips as aria-labels:

Examples of items that were already 'a' elements originally

Example for the "Like" icon:

<a role="presentation" class="Buttons__link" aria-label="Like" href="#"><i class="iconfont icon-praise_fill" aria-hidden="true"></i></a>

Note: the text in the aria-label should change to "Unlike" for posts the user has already "liked."

Example for the "Reblog" icon:

<a role="presentation" class="Buttons__link" aria-label="Reblog" href="#"><i class="iconfont icon-share1 Buttons__share" aria-hidden="true"></i></a>

Example for the reply button for comments, which already has text and does not need an aria-label:

<a role="presentation" class="CommentFooter__link" href="#"><span>Reply</span></a>

Examples of clickable text wrapped in an 'a' element

Example for the payout value which displays more details about the post/comment's pending payout when clicked ("$1.00" is just an example value):

<a role="presentation" class="Buttons__link" href="#"><span class="Payout"><span class=""><span>$<span>1.00</span></span></span></span></a>

Example for the button to show who has voted (liked) on a post/comment (the "10" for the number of voters is just an example value):

<a role="presentation" class="Buttons__link" href="#"><span class="Buttons__number Buttons__reactions-count"><span><span>10</span><span></span></span></span></a>

Example for the "Comments" item in the menu on a user's profile page:

<li class="UserMenu__item" role="presentation" data-key="comments"><a href="#"><span>Comments</span></a></li>

Note: if desired, add some CSS styling to remove text decorations and hide the fact that the text is a link.

Example of a Markdown editor button

Example for the bold button in the Markdown editor:

<button type="button" class="ant-btn EditorToolbar__button" aria-label="Add bold"><i class="iconfont icon-bold" aria-hidden="true"></i></button>

Benefits

Front ends like Busy.org allow people to interact with the STEEM blockchain in a user-friendly way. The more users that have access to these front ends, the more users will be able to use STEEM. Ideally, users with disabilities should also be able to access the front ends' features just as users without disabilities can. While screen readers are not a solution to all kinds of disabilities, making sure all of Busy.org's features are accessible to screen readers and through keyboard navigation is a significant step towards making the site usable by as many people as possible. Without a doubt, this would make Busy.org an even better front end to the STEEM blockchain.

GitHub Account

https://github.com/aiyumi