Tag: people

Day 62: Identifying A11y Issues for Voice Input Users

Speech input software is an assistive technology and strategy that people use when they have difficulty using a keyboard or mouse. This may include people with motor, visual, or cognitive disabilities. In the 21st century, it’s an excellent alternative for people in all walks of life.

Things I accomplished

Watched:

Read:

What I learned today

Windows 10 has built-in speech recognition?? It sounds like a combination of Cortana and Speech Recognition could be a cheap alternative to Dragon, but I’d need to experiment a bit with both to compare.

Apple has a Dictation feature. So, somewhat like Windows, a combination of Siri and Dictation could be used. I’ve avoided setting up dictation just because of the privacy flag that pops up when it asks permission to connect to an Apple server and learn from your voice over the Internet. Maybe I’m just paranoid and they all actually work that way?

Dragon offers some ARIA support, but it appears to be limited, and should be tested if relying on aria-label, specific roles, etc.

Love this catchphrase from the Web accessibility perspectives video:

“Web accessibility: essential for some, useful for all.”

Challenges that people who use speech recognition software face on the web:

  • carousels that move without a pause button
  • invisible focus indicators
  • mismatched visual order and tab order
  • mismatched linked image with text and alternative text
  • duplicate link text (e.g. Read More) that leads to different places
  • form controls without labels
  • hover only menus (MouseGrid can struggle accessing these)
  • small click targets
  • clickable items that don’t look clickable
  • too many links

Designers and developers should focus on WCAG’s Operable principle. In particular, Navigable guideline’s success criteria would apply here. If many of those success criteria are met with other users in mind, it will definitely be beneficial to speech recognition users, too.

In the past, I haven’t personally been interested in software, like Dragon, yet looking from an accessibility point of view, I’m ready to start testing with speech input technology to better understand how it works and affects people who rely on it when interacting with the web.

Day 61: Identifying A11y Issues for Users Who Magnify Their Screen

Things I accomplished

Read:

Watched:

What I learned today

Windows has a built-in magnifier, as does Apple, but it often isn’t always strong enough or robust to help everyone with low vision. Alternative magnification software includes:

For mobile, I knew Apple phones and tablets had zoom built in, but Android devices have magnification built-in, too.

Apple Watch has a zoom feature (YouTube)!

Trying to learn all things accessibility, I’m constantly having to rediscover keyboard shortcuts:

  • Windows Magnifier: Windows + +
  • Apple Zoom: Option + Cmd + 8

 

Never assume that two low vision people are alike. Everyone with low vision has their underlying reasons of why they struggle with that disability. The point is to add flexibility for their particular experience with low vision and the strategies they use to access content and services on the web.

Challenges people who enable magnification may encounter on the web:

  • text as images become blurry and pixelated when magnified
  • unclearly marked sections/landmarks can make navigation slow when a user only see a small portion of the screen and they’re trying to differentiate navigation from main content from a footer
  • headings that look too much like paragraph text
  • unclear link text
  • scrolling, flashing, or moving objects (carousels, I’m glaring at you again)
  • drawn out content that doesn’t provide a quick intro or conclusion at the beginning
  • horizontal scrolling
  • page content referred to by it’s position (e.g. “to the right”)
  • meaning is conveyed by color alone
  • forms with fields and labels that are not close together or positioned on one line together

WebAIM’s advice:

“The general rule when designing for low vision is to make everything configurable. If the text is real text, users can enlarge it, change its color, and change the background color. If the layout is in percentages, the screen can be widened or narrowed to meet the user’s needs. Configurability is the key.”

WCAG supports people with low vision through it’s perceivable principle. 15 reasons to consider designing to include low vision users who magnify their screen:

  • 1.1.1 Non-text content (A)
  • 1.3.1 Info and relationships (A)
  • 1.3.3 Sensory characteristics (A)
  • 1.3.4 Orientation (AA)
  • 1.4.1 Use of color (A)
  • 1.4.3 Contrast (minimal) (AA)
  • 1.4.4 Resize text (AA)
  • 1.4.5 Images of text (AA)
  • 1.4.6 Contrast (enhanced) (AAA)
  • 1.4.8 Visual presentation (AAA)
  • 1.4.9 Images of text (no exception) (AAA)
  • 1.4.10 Reflow (AA)
  • 1.4.11 Non-text contrast (AA)
  • 1.4.12 Text spacing (AA)
  • 1.4.13 Content on hover or focus (AA)

Day 57: Comparing AT and Strategies of People with Disabilities

Before I move into the “Identifying accessibility issues/problems” section of the WAS Body of Knowledge, I needed to recap for myself what I learned this week about people with different types of disabilities, the barriers they run into, strategies and assistive tech they use to overcome barriers, and the WCAG principles that benefit each one. I ended up with an imperfect table visualization as I tried organizing my thoughts on what I’d learned this past week, as well as the entirety of the past 56 days.

Thing I accomplished

What I learned today

It’s no easy task trying to visualize comparisons (in table format) of disability types and strategies used to interact with the web. For one, pigeon-holing any disability is tough, due to the nature of variety within any disability type. And organizing that information for me to better understand what strategies and assistive tech may be used in different instances really challenged me in considering what the best way was to approach this visualization. My personal cheat sheet as a 2D table doesn’t do the information justice. There are experts out there who have likely wrestled with this themselves.

Assigning the WCAG principles to each instance helped me really think about why these principles were developed and how invaluable they are to many people in a very real and personal way.

Day 55: Users with Auditory Disabilities

Auditory disabilities range from different levels of hearing difficulties to deafness, and may even include deaf-blindness. Being inclusive of this group seems fairly straightforward and easy (albeit captioning may require some budgeting).

Things I accomplished

What I learned today

Users that are deaf from birth may have sign language as their first language. Text information on websites can be their second or third language. Icons, illustrations, and images can help enhance clarity of information provided on a website.

In order to include people with auditory disabilities, web designers and developers need to review the WCAG perceivable principle. Effective strategies of accommodation for the hearing impaired include:

  • Providing transcripts and captions alongside any content that has audio;
  • Creating media players that can display captions and offer options to adjust text size and color of those captions;
  • Providing options to stop, pause, and adjust volume of audio content within the customized media player;
  • Posting high-quality foreground audio that is clearly distinguishable from background noise; and
  • Writing text in simple, clear language.

Offering sign language video as an alternative can be a nice-to-have (WCAG SC 1.2.6, Level AAA), but it isn’t always the right solution for every person with a hearing impairment. Though deaf culture is a thing, designers should never assume that every deaf person knows sign language. Additionally, it can be hard to clearly see sign language provided via web video.

It is controversial to use the word disabled in conjunction with a deaf person. Many within that community don’t consider themselves disabled due to the fact that they are thinking and capable people.

 

Day 54: Users with Motoric Disabilities

More on people with various disabilities. Today’s exploration led me to learn more about people with different motor disabilities. This group may include people with cerebral palsy, multiple sclerosis, quadriplegia, and arthritis.

Things I accomplished

What I learned today

When considering people with motor disabilities, web designers and developers should hold fast to WCAG’s operable principle. Specific important concepts includes creating a usable interface that:

  • is keyboard navigable (this also benefits voice activated software)
  • tolerates user error
  • provides alternative navigation methods to skip over lists of links, repetitive sections, and lengthy text
  • sets important stuff above the fold
  • offers autocomplete, autofill, or autosave
  • enables extended time limits
  • manages off-screen items appropriately (display:none, visibility:hidden when out of view)
  • provides clear focus outlines
  • provides large target (clickable) areas (buttons, links, controls)

There are one-handed keyboards for people with the use of only one hand. Other assistive technologies that can be used by those with more severe paralysis include head wands, mouth sticks, voice recognition software, switch access, and eye-tracking.

 

Day 53: Users with Cognitive Disabilities

Users with cognitive disabilities can include a wide scope of people, including autism, Down syndrome, Alzheimer’s, and ADHD. Persons in this category may have trouble concentrating, experience a neurophysiological disability, or struggles with a level of intellectual disability. People with cognitive disabilities may use some of the same strategies that people with reading difficulties use in order to navigate the web. Additionally, some people in this group may use assistive technology that assists with writing on the web.

Things I accomplished

What I learned today

Things to consider as a web developer/designer when trying to include this category of disability:

  • Clean and simple layout / presentation is of utmost importance.
  • Images and multimedia should supplement text, when possible.
  • Provide clear and consistent labels.
  • Utilize convention with predictable interactions.
  • Offer options to suppress distractions, like carousels, animation, and media.

This population is larger than those with all other physical and sensory disabilities combined, and yet it’s harder to use a universal solution for everyone within this group (due to the scope of abilities categorized within this group).

Memory and organization are two big challenges that this group has to overcome on a daily basis.

 

Day 52: Users with Reading Difficulties

Screen readers. They’re just for the blind and visually impaired, right? Wrong! There’s a whole other class of screen readers and screen reader users that often get little recognition. I’m talking about people who have difficulty reading. This group contains a wide spectrum that may include, but is not limited to, people with ADHD, dyslexia, Irlen syndrome, or memory loss. And I’m accusing myself of not acknowledging this group when it comes to envisioning people who use screen readers (text to speech technology).

Things I accomplished

Watched:

Read:

What I learned today

There is a stark difference between screen reader use by people with reading difficulties as compared to the blind. For one, the first group doesn’t need all things read. They mostly need assistance with having some text read aloud, rather than having everything read aloud along with additional navigational aids. A couple of screen readers that benefit this group:

Another strategy that people with reading difficulties use to access content on the web is to change styles on a web page or document. This includes customizing font size, color, and family. Using true text, rather than text inside of images, makes the reading experience for this group of people more enjoyable and inclusive.

Examples of barriers that may stand between people with reading difficulties and the web content they pursue:

  • Complex navigation mechanisms and page layouts.
  • Complex sentences and unusual words.
  • Long passages of text without images, graphs, or other illustrations.
  • Moving, blinking, or flickering content, and background audio that cannot be turned off.
  • Web browsers and media players that do not provide the ability to suppress animations and audio.
  • Visual page designs that cannot be adapted using web browser controls or custom style sheets.

Day 51: Users with Low Vision

Continuing on through the WAS Body of Knowledge, I’m currently working through concepts that involve building websites that accommodate strategies used by people with disabilities. Today I focused on those with low vision. I’m personally familiar with the group the most, and yet the strategies that people with low vision use to access web content can vary greatly. So, I consider there is still room for me to learn here.

Things I accomplished

Watched:

Read:

What I learned today

There are several low vision users that use screen readers, but often times they make the most out of the vision they do have by:

  • Using text enlargement and zoom in the browser
  • Changing colors, contrast, or fonts in the browser or operating system
  • Using magnifying tools
  • Using keyboard commands in conjunction with mouse to speed up interaction

ZoomText Magnifier/Reader is a Freedom Scientific product (the same company that produces JAWS). It appears to be a very robust program, offering enhancements to increase visibility of content, cursor, and focus. Additionally, it has a screen reader function, and has a toolbar that lets the user search and find by text, headings, lists, tables, etc (unified finder). ZoomText and JAWS can work together.

“VoiceOver can describe images to you, such as telling you if a photo features a tree, a dog, or four smiling faces. It can also read aloud text in an image — whether it’s a snapshot of a receipt or a magazine article — even if it hasn’t been annotated.” WOW. I tried this on my iPhone and verified that it could describe a picture of my son outside in the snow. My mind was BLOWN. This technology makes me very happy for one of my blind friends!

iOS magnification can jump from 100% to 1500%. Android phones have magnification, too.

High contrast text, color inversion, and color correction are available on Android 5.0+, however, they are still considered experimental features. That’s interesting, considering these are solid accessibility options on iPhones.

 

Day 30: Reminders of the Who, Why, and How of A11y

After learning a bit this past week about principles and concepts to create JavaScript that is accessible, I used today as a chance to remind myself of who we are doing this for, why it’s helpful to them, and how we can strive to meet them where they are.

Spending an hour of my time today, I used IAAP’s Prepare for WAS online resources list to get me started.

Things I accomplished

What I learned today

  • Access to information and communications technologies, including the Web, is defined as a basic human right in the United Nations Convention on the Rights of Persons with Disabilities (UN CRPD).
  • Accessibility really involves the cooperative of several moving parts for it to work:
    • content
    • user agents (browsers, media players, etc)
    • assistive technology
    • user knowledge and experience
    • developers, designers, content creators
    • authoring tools, and
    • evaluation tools.
  • I’m very familiar with assistive technologies when it comes to users being able to access websites. However, learning about adaptive strategies was new to me, though it rang true. Adaptive strategies include increasing mouse size, turning on captions, and reducing mouse speed. These techniques are usually how a user adapt with more mainstream technology.