March 2015

Volume 30 Number 3

Modern Apps - Design and Develop Accessible Modern Apps

By Rachel Appel | March 2015

What value is there in technology—the Internet, apps and various forms of media—unless there’s a human benefit? Unfortunately, there’s a lot of software out there that doesn’t benefit all people. Designers, management and developers often pay more attention to security and performance than accessibility. Accessibility is usually a low priority in software, if it’s even a priority at all.

Accessibility should be a higher priority. WebAIM estimates 20 percent of Web users have accessibility needs or rely on assistive technologies. That’s more than 60 million people in the United States alone who may have difficulty using your Web site or app or consuming your content. For most Web sites and apps, lost customers equates directly to lost revenue. My PDF, “The Importance of Accessibility,” illustrates the many other reasons for an accessible design (download it at bit.ly/1CIx4k4).

The ABCs of Accessibility

When designing and developing with accessibility in mind, consider the broad categories of disability:

• Visual: People with visual impairments range from low vision to blindness, including a spectrum of color blindness.
• Hearing: Hearing impaired people might be hard of hearing or fully deaf.
• Motor: There are many people with motor disabilities. Some have suffered complete loss of or use of limb. Others may have neuropathy from an accident or illness. People with a motor impairment might need specialized input devices altogether.
• Cognitive: People with learning disabilities, including ADHD and dyslexia, often have difficulty consuming information, depending on its presentation.

Many people require some form of assistive technology. Assistive technology is any tool or technology used to assist in daily activities to make them easier or possible. People rarely consider eyeglasses to be an assistive technology, but they are—albeit at the low end of the technology scale. Some technology users can’t function at all without their glasses. Common assistive technologies include braille readers, mouth sticks, head wands, adaptive keyboards, voice-recongnition software and so on.

 Accessible Content and Design

You’ll find the most accessible design is often considered great design. Too many Web sites have too many ads jammed into the flow of the content, which greatly disrupts the reader’s flow. Others have hard-to-use menus and navigation aspects. The layout and navigation of a Web site or app are important considerations when considering accessibility needs.

When organizing content, separate it into distinct sections with clear headings. Movies, music and animations should include captions or transcripts as part of their content. Most of the movie-­making software available today lets you enter transcripts for closed captioning.

Good design also means a consistent and clear navigation scheme. JavaScript cascading menus are often difficult for users with no disability. They’re worse for those with a motor impairment. Links across the top or down the side of a Web page work best. In phone apps, you’ll want to go along with the navigation scheme of the target device. For more on navigation in Windows 8.x, see my August 2013 column, “Navigation Essentials in Windows Store Apps” (msdn.microsoft.com/magazine/dn342878).

Fonts should be large and clear. Script-like fonts are more difficult to read. There are many things that can cause some letters from a font to be unclear. One is the learning disorder dyslexia, which causes an inability to distinguish between letters that look alike. An estimated 5 percent of the population has dyslexia. Letters that face one way to non-dyslexics look flipped and backward to dyslexics.

Using this knowledge about dyslexics, the folks over at dyslexiefont.com created a font that changes letters slightly so they’re easier for dyslexics to read. So far, font testers report they love it. You might choose not to use dyslexiefont and that’s OK. It doesn’t mean you’re snubbing dyslexics. However, be sure to choose a font that is as easy to read.

You might want to rethink changing your font if your app targets entrepreneurs. Font colors should also have high contrast. A good example of high contrast is a light or white background with dark or black text. The complete opposite is true, too. Using light text on dark backgrounds also works well. Usually it’s a matter of preference and style as to which to use, as long as there’s sufficient contrast.

You can’t go wrong with a mobile-first design strategy. Mobile-­first designs generally force you to make the best possible use of space. Most phones and small tablets only have a few inches of space for content. This means the app usually only presents the most-critical information. In this scenario, there simply is no room for vertical ads.

There are other good design practices you can follow that also help ensure accessibility. Think of the most popular news and social sites on the Web. Many of them aren’t accessible, or are only accessible to a small degree. They often contain popups that get in the way and can completely stop screen readers and humans alike. These same popups often have tiny close buttons that are difficult to find, and impossible to click or tap—even with mainstream devices.

Others employ serial popups. When you finally get rid of one popup; another takes its place. This is frustrating. Many people with accessibility needs refuse to visit these sites, as they just aren’t worth the hassle.

Avoid strobe effects, flashing effects, or images flickering without warning. This poses a seizure risk. Plus, these are usually annoying unless they’re specifically supposed to be an optical illusion or eye trick.

Don’t user color alone to convey your message to users. For example, many forms use a red font to denote a required field. Colorblind people can’t see that difference. Don’t just use the phrase “click here” as link text. That doesn’t help screen readers at all. Use something descriptive instead.

Program Accessible Code

There are programming techniques you can use to develop accessible Web sites and apps. As a developer, you need to interact with both input and output. This means you should keep in mind that different people need different ways to interact with your software instead of just the mouse and keyboard. 

For those who mostly or exclusively use the keyboard, ensure field tab orders are straightforward and in order. You should also label fields and elements such as buttons using the HTML <label> element. This ensures greater clarity. Images should have alt attributes set to something descriptive yet succinct. Screen readers can’t magically read images, so they use the alt tag to describe the image to the listener.

HTML5 contains a set of elements called semantic elements. The point of these is so both machines and humans can easily read and understand HTML elements. Semantic elements describe their content much like XML. For example, anyone can understand the following semantic elements just by reading them: caption, figure, article, footer, header, summary, time, nav, mark and main, to name a few.

For those who rely on a screen reader, skip links are life savers. A skip link lets a reader pass over navigation elements and ads on a Web site and go directly to the desired content. Having to sit through multiple, excruciating and unnecessary iterations of options and ads is no fun. Don’t force your users to sit through such a painful experience. Immediately following the <body> element is where the primary skip navigation link goes, as the following code shows:

<body>
<a href="#maincontent">Skip to main content</a>
<nav><!-- navigation here --></nav>
<main id="maincontent">
<p>The quick brown fox jumps over the lazy dog.</p>

When a screen reader sees the skip link, it focuses on the element the skip link refers to by its id. That means in the earlier example, the skip link points to the <main> element with an id of “maincontent.” Because skip links must be the first element and many designers prefer the skip link go somewhere else, you can hide it, yet make it visible to assistive technology with some CSS, as shown in this code:

.skiplink-offscreen {
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

As you can see, it’s an absolute positioned class selector with a value attribute set to -10000px. Its overflow is hidden. The code is positioning the element that uses this selector where the user will never see it, but a screen reader will. Screen readers skip over elements with the hidden or display attributes set to hidden or none. That’s why you should use this small hack.

Develop with ARIA

Accessible Rich Internet Applications (ARIA) are a set of standard attributes you can apply to markup such as HTML that help assistive technology work efficiently. With ARIA, you can define an element by its state, property or role. From that information, screen readers can determine what the software is doing.

For example, a checkbox may have an ARIA checked state. Or an element might assume the role of a menu. This bit of extra information about the state or role helps screen readers construct a better representation of the Web page’s content. These attributes don’t change the element, but they do make the element behave in a more semantic nature. Semantic markup is easier for both humans and machines to understand. For example, the following code shows an article with one section that’s semantic, so a screen reader can better identify related content and convey it to the user:

<article>
<section aria-labelledby="ProgrammingBestPractices">
  <h2 id="ProgrammingBestPractices">Best Practices for Programmers</h2>
  <ol>
  <li>Take a few minutes a day to refactor small portions of code.</li>
  <li>Learn a new programming language every year.</li>
  </ol>
</section>
</article>

You can extend this semantic and accessible markup into HTML forms. Screen readers need to know what elements label or describe form fields, and which fields belong together as a group. The state of buttons and checkboxes are other things about which screen readers must know. Good form design means knowing how script affects assistive technology. You might want to reconsider code that automatically sets the focus to a control or dynamically changes the state of form controls.

Use the HTML <label> element to label individual form elements to single labels. However, there will be times when you need to label an element with multiple labels, such as in a table. That’s no problem. The aria-labelledby attribute works in those cases. Set the aria-labelledby of each element in the group to the ids of element that will do the labelling. You can use both the <label> element and the aria-labelledby attribute in the same form. There’s no need to label Submit or Reset buttons, unless they’re image buttons. Then be sure to set the alt attribute.

Every form has required elements and elements with specific restrictions on the type of data they’ll accept. Most forms run some JavaScript to perform validation on required and constrained fields. They do so before sending all the data back to the server for processing, as it’s better to notify the user of errors sooner rather than later. Screen readers have a difficult time discerning what’s happening in the page when a script is running. To work around this, use the aria-required and aria-invalid attributes, as shown in Figure 1.

Figure 1 Accessible HTML Form with ARIA Attributes

<form>     
  <div>
    <label for="name">* Name:</label>
    <input type="text" id="name" aria-required="true" />
  </div>
  <div>
    <label for="checkboxGroupLabel">* Language</span>
    <ul role="radiogroup" aria-labelledby="checkboxGLabel">
      <li role="checkbox"><input type="checkbox" value="C#"
        name="language" aria-checked="false" />C#</li>
      <li role="checkbox"><input type="checkbox" value="JavaScript"
        name="language" aria-checked="false" />JavaScript</li>
      <li role="checkbox"><input type="checkbox" value="Python"
        name="language" aria-checked="false" />Python</li>
    </ul>
  </div>
  <div>
    <span id="yearsLabel">* Years Experience</span>
    <select name="YearsExperience" aria-labelledby="yearsLabel" >
      <option value="1">1-5 Years</option>
      <option value="6">6-10 Years</option>
      <option value="10">10-20 Years</option>
      <option value="20">20+ Years</option>
    </select>
  </div>
  <div>
    <input type="submit" alt="Submit" />
  </div>
</form>

Also shown in Figure 1 is an example of aria-required and aria-labelledby, as well as using roles. You’re just adding some extra but unobtrusive HTML. It doesn’t take much effort, and it provides a huge return.

Assistive technology must deal with more than static elements. JavaScript, AJAX calls and SPA-style apps all frequently change the contents of Web sites and apps. Sometimes dynamic script such as this gets directly in the way of screen readers. You must reset the state of some ARIA attributes, such as aria-invalid, after JavaScript validation runs.

Test Accessible Code

Test your work by downloading screen-reading software and trying out assistive technologies for yourself. Close your eyes and use the screen reader as if you were blind. Getting feedback from your users who use assistive technology is also a great way to see how accessible you’ve built software. Some screen readers you can download and use include:

• NVDA: nvaccess.org
• JAWS for Windows: bit.ly/1yJkxuV
• Window-eyes: gwmicro.com
• VoiceOver for OS X: bit.ly/1JuA1q9

Once you’ve tested for readers, WebAIM has a comprehensive checklist and page scanner called the Web Accessibility Evaluation tool (WAVE for short), that will report errors, warnings and other information about the accessibility status of a page. It’s simple to use. Go to wave.webaim.org and enter the URL you want to scan. WAVE displays the target page inline and annotates trouble spots and elements you can change to improve accessibility. Figure 2shows the scanner in action as it flags some items on the MSDN Magazine January 2015 issue page.

Figure 2 MSDN MagazineAfter Running Through the WAVE Scanner

Click on any of the annotated elements and WAVE will display error information or metadata about the element. The scanner looks at everything from missing labels and alt attributes to contrast problems. It flags them as errors or warnings so you can change the more important problems first. You can run a standalone version of WAVE, or you can add the API to your automatic QA processes.

Wrapping Up

Accessible design is usually a better design approach for everyone. A non-accessible design misses out on a substantial percentage of the population, so it’s simply a smart business decision to put in the effort to make your software accessible. UIs should present clearly labeled, easy-to-find options, and make steps to complete a task straightforward and simple.  When you design for accessibility, you automatically get an easy-to-use and straightforward system that works well for everybody.

Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, Mix and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.

Thanks to the following Microsoft technical expert for reviewing this article: Frank La Vigne