Meet new singles in your ARIA: Swipe right for accessible HTML

Illustration of  Rachel Comerford.

As the Director of Content Standards at Macmillan Learning, Rachel Comerford helps to implement and maintain industry and internal standards in content, platforms, and processes. Her work includes establishing internal accessibility, metadata, and EPUB implementation guides that align with best practices. She co-chairs the w3c Publishing Community Group and participates in working groups at IMS GlobalBISG, and AMAC where she asks lots of annoying questions and competes for the title of “most snarky.” She enjoys lazy strolls on the beach, red wine, and well-constructed EPUBs complete with all of their accessibility features and metadata.

Rachel Comerford will be speaking at ebookcraft 2018 in a session called EPUB and Chill: Finding ebooks worth a right swipe.

Dating and EPUB accessibility are both difficult to master, but neither are as difficult as trying to compare the two. Enabling users of matchmaking technologies to find their way through hundreds of misleading dating profiles requires embedding metadata about human interpersonal romantic commitments. My version of the ARIA (Accessible Romantic Interpersonal Applications) rules help users of matchmaking technologies navigate relationships.

This document is not part of the WAI-ARIA suite described in the WAI-ARIA Overview or the Digital Publishing (DPub) Module, but I highly recommend you check those out if you’re looking for useful information.

ARIA (the real ARIA: Accessible Rich Internet Applications) specifications were written in order to bring content and assistive technology together in such a way that they communicate meaningfully. I have creatively expanded the notes on using ARIA to include some advice that works in both environments.

The Rules

First rule of ARIA: Don’t try to recreate what already works

What do they say? A picture is worth a thousand words? So go ahead and post one of those classy gym selfies. But stop there. Because when you post four gym selfies in your profile I wonder if you just go to the gym to take pictures. And when you follow your four pictures with “I LOVE CROSSFIT” in all caps, I have swiped left before you can say “roid rage.” Alternately, if you post photos of your zombie pub crawl, colour run, and Rocky Horror Picture Showcosplay, you don’t need to open your profile with “I like to have fun.”

WAI-ARIA: If you can use a native HTML element or attribute that works the way you need it to, do it. That’s preferable to re-purposing an element and adding an ARIA role, state, or property.

Second rule of ARIA: Don’t change the default communication style

When you approach someone in a bar, do you pull down your pants immediately after introducing yourself?

For example: Man wants to build a conversation via text.

Do not do this:
<img src="picture_I_took_in_my_bathroom.jpg" alt="Unsolicited Phallus"/>

Do this:
<img src="picture_of_my_dog.jpg" alt="Actual, adorable puppy"/>

WAI-ARIA: Do not change native semantics unless you really have to.

For example: Developer wants to build a heading that's a tab.

Do not do this:
<h2 role=”tab”>heading tab</h2>

Do this:
<div role=”tab”><h2>heading tab</h2></div> 

Third rule of ARIA: Make sure there are multiple methods for access

Human beings are complex creatures and our emotional bandwidth is not limited to asking for a hookup or commenting on a person's appearance. Try to break through with a deeper level of communication than “Me Tarzan, you pretty.” 

Do not do this:

This works:

WAI-ARIA: If your user can click, tap, drag, drop, slide, or scroll with a mouse, then they must also be able to do so using a keyboard with standard keystrokes or keystroke combinations.

Fourth rule of ARIA: Don't hide important facts

Don't use the internet to hide physically important elements.  

<status aria-hidden="true">Married</status>  

Decorative image.

However, feel free to hide that which is not visually relevant or true:

<puppy aria-hidden="true">I know there are three pictures of me with this dog but it’s not actually mine. I just borrowed it for the pics.</puppy>

WAI-ARIA: Do not use role="presentation" or aria-hidden="true" on a visible focusable element. Using either of these on a visible focusable element will result in some users focusing on nothing.

If an interactive element cannot be seen or interacted with, then you can apply aria-hidden. For example:

button {visibility:hidden}
<button aria-hidden="true">press me</button> 

Fifth rule of ARIA: Use appropriate names

Whether you're looking for love forever or looking for someone to love for the five minutes I guarantee this "gentleman" would last, names mean a lot. If I want to call your mother and ask her if she knows how you treat women, it's safe to say you’re doing it wrong.

Decorative image.

WAI-ARIA: All interactive elements must have an accessible name.

An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value. For example, the input type=text in the code example below has a visible label "user name," but no accessible name:

user name <input type="text">


<label>user name</label>
<input type="text"/>

In comparison, the input type=text in the code example below has a visible label "user name" and an accessible name. This example has an accessible name because the input element is a labelable element and the label element is used correctly to associate the label text with the input.

<label>user name <input type="text"></label>


<label for="uname">user name</label>
<input type="text" id="uname"/> 


Sure, the metaphors are tenuous at best, but accessible EPUBs and dating have more in common than first meets the eye. Validation tools are buggy and confusing, the success criteria are a mess, and interoperable implementations are hard to find. But the investment is worth it in the end: creating an ebook you know anyone can use and finding that one person only you can use.

As I said, tenuous.

If you'd like to hear more from Rachel Comerford, register for ebookcraft, March 21-22, 2018 in Toronto. You can find more details about the conference here, or sign up for our mailing list to get all of the conference updates.