Apr 01

The low-vision experience with an iPad

I’ve met many small business owners with low vision that love using an iPad, or other tablet, as their key device. The iPad allows entrepreneurs to use a single device to handle all of their business tasks, such as point of sale, payroll, accounting, purchasing, and creating estimates on location. As a person with low vision, the built-in zooming functionality makes it easy to explore the screen and interact with the elements.

Karo Caran introduces how a person with low vision uses an iPad in this video

She recently created this new vidoe for a presentation on design for low-vision users. There are some key takeaways, such as consistency of banners and using background colors to differentiate between header, body, and footer.

Inheriting user preferences

While zooming is a great way to review content, not all low vision users want to use their applications in this manner. Many simply want to user the built in settings for higher contrast, bigger text, and reduced transparency to use their iPad without continually zooming in and out.

Your applications can automatically inherit these functions if you use standard iOS/Android components and the iOS Dynamic Type. If the app isn’t using Dynamic Type, we’ll need to check for a user’s display preferences and modify the fonts, colors, animation, etc.

Bold Text

The following code checks to see if a person has bold text enabled in their preferences. If so, use Avenir medium instead of light

+ (NSString *)fontName {
    if (UIAccessibilityIsBoldTextEnabled()) {
            return @"Avenir-Medium";
    }
    return @"Avenir-Light";
}

Darker Colors

We can detect if a user prefers darker colors, this is especially helpful for links that sit on colored backgrounds

+ (UIColor *)detailColor {
    if (UIAccessibilityDarkerSystemColorsEnabled()) {
        return [UIColor blackColor];
    }
    return [UIColor grayColor];
}

Additional Checks

Feb 05

Keyboard Accessibility with the Space Bar

Keyboard accessibility is critical for your users that depend on voice recognition, onscreen keyboards, screen readers, ergonomic accessories, and your power users that prefer to avoid grabbing the mouse for every task. Most people test to make sure every interactive element can receive focus via the tab key and that buttons and links work with the enter key. We’ve gotten pretty good at making sure links have href attributes and using role=”button” on our pseudo-buttons.

But this doesn’t cover a significant portion of keyboard accessibility: the space bar. This page includes various interactive elements to see which ones will work with a space bar.

As developers, you don’t have to worry about whether an element works correctly with a spacebar if you use the proper, semantic tag. But if you find yourself re-assigning roles with ARIA than you may need to listen for the space bar key.
Continue Reading Keyboard Accessibility with the Space Bar

Feb 03

Block level links and screen reader support

Daniel Göransson introduced VoiceOver’s contradictory support for block level links on a mailing list for Apple accessibility. Specifically, Safari + VoiceOver on OSX allows the link to be announced as a single object, whereas on iOS, the link is announced as individual elements.

Prior to HTML5, the link tag was an inline element and was not meant to contain block level elements, such as headers. This led engineers to create multiple links as designs included teasers and id card modules. These may include a thumbnail photo, header, abstract, and read more link. Bruce Lawson describes this code simplicity: Block level links in HTML5.

Göransson describes the desktop vs. phone behavior:

In Mac Safari and VoiceOver using tab key all items get announced and works perfectly. But in iOS Safari and VO using swipe to next item or touch exploring, each item get announced separately.

This is actually the intended behavior, as Chris Fleizach explains:

iOS is much flatter than MacOS, so we want to give individual access to each element within a link. Whereas, on the Mac, you can navigate inside of that link group if you so desire.

So how could we trigger mobile users to hear the content as a single chunk instead of individual elements? The following code snippets are inspired by Göransson’s emails. He deserves credit for the ideas, I can accept blame for mis-representation.

Please Note: you may find it easier to view these examples outside the WordPress framework. Visit the block level example page.

Base code snippet

This example has a header, paragraph, and image. I’ve placed alt=”” on the image, as the surrounding text provides adequate description.

<a href="https://www.flickr.com/">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic (Δέησις, “Entreaty”) probably dates from 1261. It was commissioned to mark the end of 57 years of Roman Catholic use and the return to the Orthodox faith. It is the third panel situated in the imperial enclosure of the upper galleries. It is widely considered the finest in Hagia Sophia, because of the softness of the features, the humane expressions and the tones of the mosaic.

See the larger image on Flickr

Using ARIA to make the experience consistent

ARIA roles allow developers to define the purpose of content. Ideally, you should use the correct tag before even considering ARIA attributes. Use the role when HTML doesn’t provide an adequate tag (tabs), or the HTML equivalent is not as well supported by accessibility APIs (nav). Secondarily, roles are used to restore the semantics of code when the correct tag is not used (div based buttons).

This example is correctly using the link tag, as the user will be taken to a new source of content, such as a web site. I had initially suggested using role=”button”, as that would flatten the experience and should announce the entire content, regardless of platform.

<a href="https://www.flickr.com/" role="button">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic …

Using role=”button.

This would change the user’s expectation, as it announces this as a button instead of a link. It implies clicking on the object would trigger an action. But what is the action? Buttons should have a clear and concise call to action (“print”, “share”, “close”). This also means the link would appear within the quick menu for forms, rather than links.

Combining with aria-hidden

Göransson also noticed an unusual problem when placing aria-hidden=”true” on the image. This removed the image’s area from the touchable region.

Also when using anything with aria-hidden=”true” inside that <a>, the area where hidden item is located will become untouchable even if it’s still inside a <a>. For example, if I float an icon/image with aria-hidden to the left — that part of the <a> will be subtracted from the hitbox.

<a href="https://www.flickr.com/" role="button">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." aria-hidden="true" alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic …

Added aria-hidden=”true” to the image.

Victor Tsaran re-iterated Chris Fleizach’s suggestion of using role=”text” to allow the block to be announced as a single unit.

I am not sure you can achieve this in Mobile Safari without perhaps having to resort to the role=text. The Voice Over navigation of the DOM is much flatter on iOS than on Mac OS and you are inserting a bunch of block elements into an inline one.

<a href="https://www.flickr.com/" role="text">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." aria-hidden="true" alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic …

Using role=”text” on the link

But this changes the semantics of the link to a text node, removing it from the link menu.

Göransson’s next attempt wraps the link’s content in a div with role=”text”. This keeps the link’s semantics and the entire content is announced. However, this also removes the semantics of the h4, removing it from the header menu.

<a href="https://www.flickr.com/">
  <div role="text">
    <h4>The Deësis mosaic</h4>
    <p>
      <img src="..." aria-hidden="true" alt="">
      The Deësis mosaic ... </p>
    <p class="more">See the larger image on Flickr<p>
  </div>
</a>

The Deësis mosaic

The Deësis mosaic …

Wrapping the content within a div that has role=”text”

What is the answer?

This exploration could be summed up by Sina Barham’s tweet about trying to change the expected gestures.

While we could solve the issue of making a block level link work consistently across mobile and desktop browsers, that may not be the ideal solution. The user’s expectations are context dependent, this is especially true with navigation.

Jan 17

Positive Advertisements that Include Accessibility

Inclusion is the goal for all accessibility professionals. Our goal is to give everyone the freedom to accomplish any task independently. We also recognize the importance of social inclusion of people of all abilities. I’ve created a playlist of videos on YouTube that include people with different abilities in a positive spirit without falling into the inspiration porn mindset.

My favorites are the Wimpy’s burgers with braille buns, South Africa tourism, and the singing children from Thailand.