Programming #6: Applied Accessibility

We of course have to consider our disabled peers. Not everyone can see or hear the content we come across, so we provide alternatives.

The first obvious task is images. When the visually impaired can’t make out an image, we add a text alternative for their audio screen reader to transcribe.

Just add an alt tag with the description in the quotes.

<img src="anyimage.jpeg" alt="image description">

If the image already has a caption, you can also leave it blank, but still do the quotes.

This next task doesn’t have any special code, but it’s still important.

When the screen reader reads, it acknowledges the visual hierarchy of your text. It describes the heading as what it is, as the same goes for the subheading and paragraphs. Bottom line, keep your headings ordered. No <h1> to <h4> to <h2>.

Screen readers also give users options to jump to sections of the content. You’ve probably seen those ‘jump to main content buttons’, this is just a screen reader’s version of that. This is where HTML5 comes in. Remember, HTML5 doesn’t do anything physically to the page, it’s just for organizing the code. You can add any tag you want, usually main or footer is standard. Just place it in between whatever elements you wish. For a typical ‘main’ tag, you would place it between the header and footer elements.

Within the ‘main’ tag, we also got article and section who serve as a set and subset of content. If your post is a book summary, ‘article’ would be the book and ‘section’ would be the chapters.

There’s also the header tag, which is similar to the main tag. Keep in mind is it not the same as the ‘head’ tag, as in the page’s title.

We also have audio elements as an alternative for the visually impaired who can’t access audio content.

<audio id="audioname" controls>
<source src="audiolink.mp3" type="audio/type"
</audio>

The ‘audio/type’ is only a placeholder for whatever the actual type is, though it will still start with ‘audio/’.

Next we got figure tags. This is basically a more general version of the first task we did with the text alternative. This tag can be used for images, diagrams, charts, or any other visual content.

Its input is a basic <figure> tag, subsetted with a <figcaption> tag for the caption, just make sure you close them. You can wrap the figure tag around any content you desire, and make sure the <figcaption> goes within the figure tag.

We can ensure the screen reader acknowledges forms with a simple ‘for’ attribute.

<form>
  <label for="name">Name:</label>
  <input type="text" id="name" name="name">
</form>

This example is for creating a name-text-input. The ‘for=’ is the only attribute that specifies for the screen reader. For any other type of form, ensure your ‘for’ is the same as the ‘id’.

When a screen reader approaches a selection form (or radio buttons like we’ve done), we can add fieldset and legend tags so the reader can describe what the user is making the choices on (legend) along with listing the choices themselves (fieldset).

There’s no special code for this. In a form element, replace the ‘fieldset’ tag where the <div> would be, and replace the ‘legend’ where the title of the selection box would be, in most cases that would be the <p> tag.

Next we can add a date picker to a form; you know the little calendar you click so you can pick the date instead of typing it.

<label for="pickdate">Preferred Date:</label>

<input type="date" id="pickdate" name="date"

The top label is what first defines the input-box. We then use the ‘id’ attribute to apply our little calendar to this box. So the ‘type’ and ‘name’ are for the calendar, and the ‘id’ is what applies it the input-box.

We can use the time element with the datetime attribute to so the screen reader can emphasize it as a date and not just regular text

<time datetime="2016-09-15">Thursday, September 15<sup>th</sup></time>

The <sup> is for the superscript, (like^this) to accent the ‘th’ next to the date number. It’s not mandatory for this code, but it is typical when writing dates.

Screen reader only elements are written as ‘.sr-only {}’ with the respective attributes underneath it. We’ll come back to this later.

To give the assistive device (still the screen reader) the ability to describe links, we add anchor tags.

<a href="">the text you want to be described</a>

Adding an accesskey makes navigation easier for our disabled peers (think of it as the ‘fast travel’ function in open-world games; you can go straight to your destination without scrolling through the whole page).

It goes within an anchor element:

<a href id="who1" accesskey="w1" href="#"</a>

Once again, this allows the assistive device to point out interactive actions on our site (mainly links & buttons

We can add a tabindex. I don’t have a clear idea what “bring to focus” means yet (I’ve never used a screen reader). All I know is this goes within whatever tag you wish to focus. It’s typically set to 0.

<h1 tabindex="0"</h1>

So 0 is the default order of the tabindex. If you want to order the sections that are focused on, just add 1, 2, 3, and so on.

What I Learned Today

All of these are based on commanding the assistive device/screen reader to do something

1. Add a text alternative for an image
2. To keep the visual hierarchy in order
3. Use HTML5 tags to section content for the ‘jump to’ function (main, footer, article, section, header)
4. Add an alternative for audio content
5. Add a figure tag to specify visual content
   • Along with the <figcaption> tag to describe the content
6. Ensure the screen reader acknowledges forms
   • Along with ‘fieldset’ and ‘legend’ tags to describe the choices within the form
7. Add a date picker (the small calendar icon)
8. Specify a date with ‘datetime’
9. Describe a link
10. Add an ‘accesskey’ for focusing on different sections of the content
11. Use a ‘tabindex’

Concerns

• It seems like accesskey and tabindex are similar to the ‘jump to’ function. I can see how the tabindex keeps it ordered (it shows you 1, then 2, then 0 if nothing else), but the accesskey just seems redundant compared to simply doing a ‘jump to’ in the screen reader.
  
• The datetime seems redundant too. I don’t see how it’s any different from the screen reader simply reading the date.