All Access Pass

July 17th, 2012 | by | tags: ,

Long ago a story would air, then pretty much fade into history. That time is gone. Today stories have many lives, on-air and online. Broadcasts still get the larger one-time audience. But beyond-broadcast is where stories spend most of their existence: in podcasts, downloads, discussions, and social media shares.

We in pubmedia learned the tools for audio/video production. Now many of us also work daily with web tools. So Transom offers some articles for journo-coders, hosted by producer/programmer and Transom webmonkey Barrett Golding. Our first post is more like a demand…

Let Me In: Web Accessibility

Blind Justice, stone relief, Mississippi State Capitol building, by Shawn Rossi

“Case studies show that accessible websites have better search results, reduced maintenance costs, and increased audience reach.”
—W3C, “Why: The Case for Web Accessibility”

Like buildings and bathrooms, websites should be built so everyone can enter. You’d think civic-minded public media orgs would lead in web accessibility. Instead, many barely follow the guidelines.

Transom is now in the process of reforming our own inaccessible ways. As we figure out how, we’ll share what we learn.

Here Come the Robots

Making your webpages accessible means not only blind/deaf folk can enjoy them, but also every past, present and future browser can make sense of your site. Web accessibility is mainly just sticking to HTML standards and good coding practices. Every web accessibility technique makes your site better for all your users.

In fact your most influential user, the one that sends you half your traffic, can neither see nor hear. I’m talking about Google’s search robot. If you ignore the Web Accessibility Initiative, you’ll be ignoring searchbots — and, to some extent, they you.

Now that I’ve put the fear-of-Google in you, let me list a few ways to keep both robots and humans happy.

Access Ability

Accessibilty word cloud, by Jil Wright
You may be moving around this page with your mouse. But that’s not the only way to navigate the web. People use screen-readers, screen magnifiers, touch-screens, text-only browsers, voice commands, and keyboards. Imagine how your page would sound if it was being read? Does your code have clues as to what’s content and what isn’t (like menus, headers, and sidebars)?

Rather than repeat the many fine guidelines and slick checklists out there, I’ll link to a few, and summarize the more essential, easy-to-implement, and pubmedia-applicable considerations.

Get Your Docs In a Row: Document Structure

Think high-school writing class: Outlines — a hierarchical list of Headings and Sub-headings. That’s document structure. Every webpage has it. The better you specify your document’s structure, the more insight every human, every browser, every robot, and every search-engine has into how your page’s content is organized.

HTML has a herd of heading tags for this purpose, <h1> thru <h6>. The content structure of the headings in this document is:

  • <h1>All Access Pass
    • <h2> Let Me In: Web Accessibility
    • <h2> Here Come the Robots
    • <h2> Access Ability
      • <h3> Get Your Docs In a Row: Document Structure
      • <h3> Improve Your Image…

Almost all documents should have only one <h1> (as an article has only one title). After <h1>, heading tags should nest in numeric order, e.g., an <h2> section can be followed by another <h2> section, or an <h3> sub-section but not an out-of-order <h4>.

Build your site on a solid structure, following the code standards. Some pubmedia meaningful ones include:

Improve Your Image: Alt-Text

Images have content. Searchbots and screen-readers can’t see that content. So tell them about it using the “alt” attribute:

<img src="blind_justice.jpg" alt="Blind Justice, stone relief, Mississippi State Capitol building, photo: Shawn Rossi" title="Blind Justice, Mississippi State Capitol, photo: Shawn Rossi" width="235" height="185" />

Think of alt as your way to talk to blind folk and search-engines about your visual content. The other image attribute above, title, is for those who can see your image, a kind of hidden caption — some browsers show it as a tool-tip when you mouse-over the image. Since these two image attributes are used differently, they often have different text. In short:

  • alt is an accessibility requirement (and an HTML standard). It contains image-info text for people (and machines, such as bots) who can’t see the image. Every image should have alt-text.
  • title is optional. It contains image-info text for people who can see the image.

WordPress makes adding alt-text easy via their media Upload/Insert tool: Screenshot of WordPress: Media Uploader-  Alt and Title text

Make Links Easy to Find

Your site should identify links on your pages in at least two ways, i.e., more than just by a high-contrast text color. Colorblind people may not recognize the color difference. So, for instance, if you also underline links, everyone can see them. Another tip: when possible, make your link text more than one word. Makes the link a bigger target, so easier to hit — especially on small screens, like smartphones.

Make Links Text Descriptive

Screenshot of highlighted link textAlso the text of a link should describe what the link goes to. A common mistake is using “click here” (or “here”) as link text. That text tells search-engines and visitors nada, except that it’s a link — which they already know because your site uses two ways to identify links, right? And clicking is only one of many ways people trigger links: They tap, hit enter, and give voice commands. What if someone prints your page, what’s that “click here” get you then?

Other reasons for meaningful link text: Web browsers have settings to enable keyboard-only navigation; the tab key moves your cursor thru form-fields and from link to link, highlighting each link’s text along the way. So avoid mystery meat navigation by making sure your link text describes the link. Also, many alternative browsers generate a list of links to help users decide whether to read the content. Imagine your page as a link-list:

  • click here
  • here
  • click here…

This looks lots better:

“Explain what users will find at the other end of the link, and include some of the key information-carrying terms in the anchor text itself to enhance scan-ability and search engine optimization (SEO). Don’t use ‘click here’ or other non-descriptive link text.”
—Jakob Nielsen, Top 10 Web Design Mistakes of 2005

Every browser has a menu command that lets users choose whether to open a link in the same window/tab or into a new one. That is, unless you force a link into a new window by adding a target to your link tag. Doing that removes both the users’ choice and the back-button for them to return to your site (a new window has no history, so the back-button is off).

It also makes for a bad user experience: People often don’t notice a new tab has opened, so think your links don’t work. At the same time you’re cluttering the user’s browser bar with all the new tabs. So, for most links, let your users decide where they open — with possible exceptions for PDFs and other non-web documents.

Say What? Text Equivalents for Multimedia

Can you hear me now? No, I can’t: I’m deaf. Give me a transcript. It’s that simple: provide a text version of your audio; provide a caption and transcription of your videos.

Got to admit, tho, Transom’s as guilty of this accessibility transgression as anyone. It costs time and money to make transcripts, but we’re checking into tools that might automate the process:

YouTube offers Automatic Captioning, via Google Voice speech recognition. They let you download the auto-captions file. Many of the words will be wrong, but it’s sometimes a good start on an audio transcription.

Uploading your corrected captions gets you some side-benefits such as auto-translations into many-languages and interactive transcripts timed to scroll as the audio/video plays. Cooler still: click (or tap, etc.) on a line of text and the playhead advances to that part in the media. Like I said, accessibility techniques benefit all your visitors.

“Companies that do not consider accessibility in their website or product development will come to regret that decision, because we intend to use every tool at our disposal to ensure that people with disabilities have equal access to technology and the worlds that technology opens up.”
—Thomas E. Perez, Civil Rights Division, United States Department of Justice,
2010 Jacobus tenBroek Disability Law Symposium (PDF)

Say What You Mean: Abbreviations

This one’s easy: Put abbreviations and acronyms in an <abbr> tag, with the unabbreviated definition in the title attribute. For example, SNAFU is:

<abbr title="Situation Normal, All Fucked Up">SNAFU</abbr>

Most browsers display a tool-tip with the title attribute when you mouse-over an <abbr>. Try it (if using a mouse); hover over the following for a few seconds: OMG, it works.

To let folks know where they are, add some CSS style to your <abbr>‘s, like a dashed underline:

abbr { border-bottom: 1px dashed #555; }

The idea is to keep things clear for all readers and devices. Really, you should write out abbreviations and acronyms the first time you use them, and then use the <abbr> after that. Unclear:

This CD really rocks…

Am I talking bands or banks? Now, clearly:

This Certificate of Deposit (CD) really rocks. A 3-year term that pays 2% APY: Awesome CD, Dude.

Hey, you say, why didn’t you define the “APY” above? Good question:

  1. Tag It: Perhaps you don’t want to spell out every acronym. Maybe most people know the meaning, like USA. Maybe your readership is quite familiar with the term. Maybe you just don’t want to ruin the flow of your finely crafted prose. No problem, <abbr> tag it and all’s accessible.
  2. Link It: If you’re using jargon whose definition isn’t obvious, link to an explanation. So the abbr., accessible HTML looks like:
    <abbr title="Annual percentage yield"><a href="http://en.wikipedia.org/wiki/Annual_percentage_yield" title="Annual percentage yield - Wikipedia, the free encyclopedia">APY</a></abbr>.

For more on the how accessible abbreviations work, look, and sound, check these articles: “The Accessibility Hat Trick: Getting Abbreviations Right” at A List Apart and “The abbr element” by the HTML5 Doctor.

¿Qué dijiste? Language

Another easy one: Tell screen-readers and search-engine what language you’re using, so they’ll know how to pronounce and define your words. You do that by declaring your language (and text-direction) in your document’s <html>; United States English (left-to-right) is:

<html lang="en-US" dir="ltr">

If you use a term from another language, declare that too: it’s a mitzvah (Hebrew: מִצְוָה).

<span lang="he" dir="rtl">מִצְוָה</span>

That’s it for now. Next time:

  • Function Follows: Forms
  • Show Me the Content: Skip Navigation Link
  • Not Design, Data: Tables
  • Eye of the Beholder: Colorblind
  • The Strong and the Bold: <b> <strong> <i> <em>

Image credits (Creative Commons licensed):
Blind Justice, © Shawn Rossi
Accessibility word cloud © Jil Wright.

2 Comments on “All Access Pass”

Leave a Comment