Tag: people

Benefits of Accessible Design

Accessible designs often benefit everyone. The most obvious group to benefit is people with disabilities. Independence and access is possible when public and digital spaces are built with accessibility in mind.

Organizations benefit from accessibility in several ways:

  • The organization stands out as one committed to equal opportunity and fairness;
  • The business product becomes more compatible/usable for more people;
  • Good markup, thoughtfully composed content, and text alternatives can improve search engine optimization (SEO);
  • Inclusivity increases customer base;
  • Funding eligibility from outside sources (like government) increases;
  • Chances of a lawsuit due to inaccessibility decreases.

In addition to people with disabilities gaining more independence, and businesses increasing engagement with their product, other groups in society often benefit from accessibility.  Some examples of accessible designs that have benefited people without disabilities:

  1. Curb cuts
  2. Elevators
  3. Dual height water fountains
  4. Automated doors

I would venture to guess that you have used most of the “features” I’ve listed. On a more dramatic note, independence for people with disabilities:

  1. Relieves a dependency burden from family and friends, and
  2. Increases interaction between people with and without disabilities, allowing for more friendships and meaningful companionship.

Accessible design creates better access for everyone, but that shouldn’t be our motivation. Access is a human right. Public and digital spaces should be accessible to people with disabilities. Accessible design isn’t a nice-to-have, it’s a must-have because it makes things possible for people with disabilities.

Additional Reading:

Disability Etiquette: To do or not to do

Through our recent learning, we now know the different types of disabilities, and realize just how many of people with disabilities live among us (Disability Statistics). So, how are we supposed to act around those people, anyway?? I mean, could it really be that simple to interact with other… people?

Don’t do this…

  1. Raise your voice, using a louder volume than necessary, or use baby talk.
  2. Finish another person’s sentence or interrupt while they are trying to talk.
  3. Put your hands around your mouth when talking to people who are hard of hearing or deaf.
  4. Play a game of “guess who” with people who have a visual disability.
  5. Talk about a person when they’re present or talking only to their interpreter or assistant.
  6. Force your help on them.
  7. Play with a service dog that’s on-duty.
  8. Touch, lean on, or play with their assistive device (white cane, wheelchair, etc.).
  9. Ask in-depth about their disability, despite it being their business to share.

Maybe do this…

  1. If a person looks like they are struggling, offer help by asking if they need help.
  2. Say hello, like a decent human being. Acknowledge they are there and you are there.
  3. Respect assistive devices as tools, not toys or props.
  4. Ask the person about their personal preferences on how to address their disability.
  5. Be thoughtful about the words you use when speaking or writing about a person with a disability.
  6. Respect their independence.

Terminology

People-first language: Character description or label is highlighted after the person is acknowledged. Example: person with cerebral palsy.

Disability-disabled affiliation: Language that respects individuals who prefer that they are seen as disabled or a person with disability. Example: Deaf.

Not everyone feels like they are disabled or have a disability. Or they feel like they have a disability only when they run into a barrier in communication, mobility, etc. Some people are proud to be a part of a community, like the Deaf or Blind community. It’s better to not assume, but ask about the terminology they prefer. Terminology may even vary in the situation they are in or at different points in their life.

In conclusion

Appropriate disability etiquette and terminology really depends on the preferences of the person who has a disability and what type of disability they have. A person with a disability is a person, not a condition. Each person’s experience is unique. Treating them like a person is always the best course of action and etiquette. Ask (politely) how they like to be referred to or if they need help. Don’t expect them to be a disability educator and advocate all the time, on the spot; they’re out living their life, too.

Additional Reading:

Disability Statistics: What’s in a Number?

So, now you’re an expert on what types of disabilities there are, right? (see Types of Disabilities, Part 1 and Types of Disabilities, Part 2, if you need a refresher) With a widened perspective, it’s conceivable that 10-20% of the world’s population has one (or more) of those disabilities. That’s 700 million to 1.4 billion people who have either a visual, auditory, cognitive, mobility, seizure, or psychological disability. Or a combination of 2 or more of these things! Some of these disabilities are more visible than others. Regardless of what we do or don’t see, this is a general statistic that may not even count everyone because chose not to disclose their disability. Regardless of reported and actual numbers, the reported percentages are still quite significant.

Why a range between 10-20%, anyway? That’s a great question! Disability statistics are complicated, to put it mildly. Some reasons why:

  • Survey methodologies across countries vary. What and how questions are asked can illicit a different response from person to person. Data collection may be based off of self-reporting information or collector observations. The intent of the survey may prevent or encourage people to identify as disabled. So many variables!
  • The definition of “disability” can be very broad or very narrow, depending on the culture of the surveying country;
  • Political bias. This can even be as extreme as denying that there aren’t any people who are disabled in their country. It depends on how a country wants to be viewed;
  • Imbalance in population that may have a higher number of elders, impoverished, or war-affected people.

That last bullet point brings up another question: why would a higher population of elders, impoverished, or war-affected people matter when gathering statistics on disabilities? Another great question! Here’s why:

  • 30-60% of people acquire a disability, due to age, which could affect one or more of the following: sight, hearing, mobility, or cognition;
  • In countries with a life expectancy 70+ years, individuals spend about 8 years (11.5% of their life) living with a disability, due to aging;
  • Approximately 50% of 85+ year old folks have a disability, ambulatory disabilities being the most common for 65+ year old folks;
  • People with disabilities are less likely to complete their education:
    • because they can’t traverse the traditional school system and standards,
    • because the education system is ill-equipped to accommodate them, or
    • other barriers affect the quality and availability of education;
    • In the U.S. about 19% of people with a disability (ages 21-64) were reported to have less than a high school education in 2017.
  • Less education means fewer job opportunities:
    • In the U.S., people with disabilities are 2x as likely to live in poverty;
    • In the U.S., ~30% of people with disabilities live below the poverty line, and people with disabilities living in a third world country face a more bleak situation;
  • People with disabilities are often among the poorest of the poor, especially in poorer countries, and that can affect their family for generations;
  • Deficiencies in health care, sanitation, and safety increase the number of people with disabilities; and
  • Some people who have been in a war zone acquired a disability. Approximately 27% of non-institutionalized civilian veterans (21-64 years) were reported to have a VA service-connected disability in 2017.

In short, a higher population of any of these aforementioned groups within a surveyed country could affect the reported percentage of disabled people that live there.

So, what’s in a number anyhow? Empathy? Hope? Despair? Harsh reality? Are people with disabilities just a statistic? Do statistics make problems quantifiable and relatable? If so, do the numbers move you to action? Or do they just feel like percentages that have no real meaning? And yet it’s a fact that people with disabilities are people, not a condition (type) or number (statistic). We need to get serious about treating them more like people.

Additional reading:

 

Types of Disabilities, Part 1

In my experience, disabilities have been categorized in many different ways. Most commonly, I’ve seen them generalized in the following 4 categories:

  • visual
  • hearing
  • mobility
  • cognitive

In their Introduction to Web Accessibility article, WebAIM is an example of one source I’ve found these 4 categories outlined. The University of Illinois at Urbana-Champaign‘s An Introduction to Accessibility and Inclusive Design class uses the same broad categories.

In contrast, Deque’s coursework addresses disabilities with more specific categories. They propose 13 categories altogether:

  • Blindness
  • Low Vision
  • Color Blindness
  • Deafblindness
  • Auditory Disabilities
  • Motor Disabilities
  • Cognitive Disabilities
  • Dyslexia/Reading Disabilities
  • Math Disabilities
  • Speech Disabilities
  • Seizure Disorders
  • Psychological/Psychiatric Disabilities
  • Multiple/Compound Disabilities

In comparison, the CPACC Body of Knowledge breaks disability types into 9 categories:

  • Visual
  • Auditory
  • Deafblindess
  • Mobility, flexibility, & body structure
  • Cognitive
  • Speech
  • Seizures
  • Psychological/psychiatric
  • Multiple/compound

So, for the sake of staying true to the study guide, let me tackle the first 4 on the CPACC list.

Visual

Visual disabilities can refer to blindness (of varying degrees), low vision, or colorblindness. Some of these communities prefer to be acknowledged as the specific disability (blind, low vision, or colorblind) rather than visually impaired. However, it’s better to ask someone about their preferred label, rather than assuming one voice speaks for everyone.

Blindness

According to legal definition, a person is blind if they have a visual acuity of 20/200 or less with correction or who has a field of vision (what can be seen in front of the person) of 20 degrees or less in their “best” eye. In 2017 the World Health Organization (WHO) estimated 1 million people in the US and 36 million people worldwide are legally blind.

Some causes of blindness:

  • Congenital
  • Cataracts
  • Diabetes
  • Macular Degeneration
  • Glaucoma
  • Accidents or traumatic injuries to the eye
  • Stroke
  • Retinitis Pigmentosa
Digital Environments
Challenge Solution
Digital interfaces with screens
  • Screen reader
  • Interface with built-in audio or speech
  • Refreshable Braille
Inaccessible content or interface (not compatible with screen reader)
  • Designers & authors can make markup for websites and content compatible with AT.
Physical Environments
Challenge Solution
Walking independently to places
  • White cane
  • Service animal
  • GPS-based walking instructions
  • Raised tiles on the ground
  • Obstructions removed from walkways and overhangs
Signage
  • Map & geolocation apps
  • Braille labels
  • Tactile models
Consumer Products
Challenge Solution
Flat interfaces and controls
  • Tactile controls
  • Audio interface
  • Mobile app control
Text on containers or packaging
  • Braille labels
Currency
  • Mobile app to read currency
  • Redesign of currency
  • Non-cash systems of payment
Printed materials (text and images)
  • Optical character recognition software
  • Conversion to digital format
  • Conversion to Braille

Additional Reading about blindness:

Low Vision

A person is considered to have low vision if their vision is 20/70 or poorer in their best eye with correction. People with low vision often struggle to accomplish visual tasks, but with the use of assistive technologies or adaptive strategies, they sometimes can accomplish those tasks. The National Institutes of Health estimates that there are 2.9 million people in the US and 246 million worldwide with low vision.

Types of low vision:

  • blur (generalized haze)
  • blur with low contrast (generalized haze)
  • cataracts (generalized haze)
  • diabetic retinopathy (central vision)
  • glaucoma (central vision)
  • hemianopia (peripheral vision)
  • macular degeneration (central vision)
  • retinal detachment (peripheral vision)
  • aphakia (generalized haze)
  • light sensitivity
  • night blindness
Physical and Digital Environments
Challenge Solution
Small text
  • Screen magnifier
  • Software or settings to increase contrast
  • Screen reader
  • Interface with built-in speech
  • Large print
  • Digital format compatible with AT
Low contrast
  • Software or settings to increase contrast
  • Designers and content creators choose high contrast for readability

On Day 51 of my WAS certification exam journey., I posted about Users with Low Vision, which expands on some of this information.

Colorblindness

Colorblindness is the inability to distinguish between certain kinds of colors, based on brightness and luminosity. 1 in 12 men and 1 in 200 women worldwide experience colorblindness.

Types of colorblindness:

  • red-green, including red on black (Deuteranopia and Protanopia)
  • blue-yellow (Tritanopia)
  • grayscale (Achromatopsia)
Physical and Digital Environments
Challenge Solution
Color combinations with low contrast
  • Designers shouldn’t depend on color only to share information

Auditory

Auditory disabilities range from mild to profound hearing loss and deafness. Some causes of auditory disabilities:

  • genetics
  • congenital
  • premature birth
  • infections/illnesses
  • ear trauma
  • exposure to loud noises
  • aging
Digital Environments
Challenge Solution
Audio
  • Full transcript
  • Sign language interpretation
Video
  • Synchronized captions
  • Full transcript
  • Sign language interpretation
Physical and Digital Environments
Challenge Solution
Speeches or presentations
  • Sign language interpretation
  • Live captions
Physical Environments or Consumer Products
Challenge Solution
Doorbells or other alarms
  • Visual alerts
  • Tactile alerts

Deafblindess

Deafblindness is a combination of blindness and deafness. People who are deafblind encounter the same challenges as blind and deaf people would.

Digital Environments
Challenge Solution
Text or images
  • Screen reader with refreshable Braille output
Video and/or audio
  • Full transcript

Mobility, flexibility, & body structure

People with mobility impairments may experience difficulty moving, controlling, or coordinating movements of the body. Some of these disabilities subcategorized as traumatic injuries (spinal cord injury, stroke, damage to limb) or biological conditions (CP, MD, Parkinson’s, MS, ALS, RA).

Causes of mobility impairments may be due to:

  • genetics
  • premature birth
  • illnesses
  • accidents
  • aging
Digital Environments
Challenge Solution
Mouse
  • Other input devices: keyboard, alternative keyboard, mouth stick, head wand, switch device,
    speech recognition, eye tracking
  • Developers and designers ensure keyboard (and other input devices) operability
Timed sessions
  • Designers can delay timeouts
  • Designers can provide alerts for timeout
  • Designers can allow time extension
Physical Environments
Challenge Solution
Steps and escalators
  • Ramps
  • Elevators
Small spaces
  • Wider spaces for wheelchair access
  • Remove obstacles in pathways
General
Challenge Solution
Walking
  • Walker
  • Cane
  • Crutches
  • Braces
  • Wheelchair
  • Scooter
Door knobs, handles, entrances
  • Door actuators
  • Motion sensors to automate door
  • Lever handles

Additional reading about motor disabilities:

To Be Continued…

This post only covers touches on some of the categories of disabilities. Next up, I’ll be learning about cognitive, speech, seizure, psychological/psychiatric, and compound disabilities to share with you in Part 2.

Basic Disability Concepts

My first CPACC study session involved me reading through Deque’s “Basic Disability Concepts” section. I completed that in less than an hour, and took that extra time I had to start reviewing IAAP’s CPACC Body of Knowledge Word document. Within that document, I didn’t see an equivalent of the overview that I went through on Deque, but that wasn’t surprising since it was basically a perspective check before wading into the rest of the material. Though it was a short section, I still found several bits interesting, if not eye-opening.

Our diverse abilities

I think we all have some preconception of what a disability looks like. However, there’s often more to it than our own limited perspective. Did you know that 20% (1/5) of people have some form of disability, whether permanent or temporary? Alaska statistics seem to support that number wholeheartedly with 21.9% of Alaskans over 18 years of age who have a disability [Centers for Disease Control and Prevention].

In that vein, we may ask, “Are there really that many blind folks or people in wheelchairs?” However, some disabilities are not so obvious to us. We may not realize that there are people in close proximity who are deaf, have a reading disorder, experience seizures, or are colorblind. They are not wearing a sign or shouting to be noticed for their disability, if they even identify as having a disability.

Why would users of the web be any different? When creating content and experiences for the web, we should be considerate of people with:

Accessibility matters

Once we understand that a not-so-insignificant number of people have a disability and that those categorized disabilities vary in form and spectrum, we can better understand why accessibility matters. Our next step is to not make assumptions and meet people where they are. Did you know that less than 10% of blind Americans can read braille? This was one of the more surprising statistics I read, so naturally I went down the rabbit hole of searching for a 2009 National Federation for the Blind online report that offered that statistic. (I was unsuccessful.) However, this statistic is a good example of why we can’t make assumptions about people, if we want to be part of the solution to enable people with disabilities to independently make choices and take action.

Assistive technologies

As a web designer and developer, I should understand that there are many different types of assistive technologies (AT) to help people with disabilities independently access the content my website has to offer. Sometimes one AT can be used by several disability groups, even ones you wouldn’t expect. See any AT that you use to make accessing content easier for you?

Assistive Technology Disability
screen readers
  • blindness
  • low vision
  • cognitive disabilities
refreshable Braille display
  • blindness
screen enlargers (magnification, zoom)
  • low vision
color overlays
  • color blindness
  • cognitive disabilities
captions
  • deafness
transcripts
  • deafness
head wand
  • motor/mobility disabilities
mouth stick
  • motor/mobility disabilities
alternative keyboards
  • motor/mobility disabilities
eye gaze tracking
  • motor/mobility disabilities
voice activation
  • motor/mobility disabilities
augmentative communication aids
  • cognitive disabilities

By the way, AT takes on many forms and does many things, but AT can also be misunderstood.

  • AT isn’t restricted to people with disabilities. It is available to everyone. People who don’t have low vision can benefit from glasses. Parents pushing strollers can benefit from elevators.
  • AT isn’t magical. It can’t overcome barriers that were created from the start. If a website isn’t built with accessibility in mind, it’s not going to become magically accessible when a screen reader is turned on or an “accessible” overlay tool is lobbed on.

The Digital Accessibility Revolution

It’s important to recognize that the web isn’t the problem, but rather an important part of the solution to empower people with disabilities. Consider these situations:

  • a blind person wants to independently access the latest news, or
  • someone with a mobility impairment prefers to shop online because it’s easier than taking a trip to a brick and mortar mall

The idea about us designers and developers creating a problem was impactful enough for me to post on Twitter:

Perspective check

In conclusion of this brief overview of my coursework, it’s all about readjusting and widening our perspective when we offer a service to people. Without that perspective check, we can’t possibly absorb additional information about other people around us and the challenges they face on a daily basis. Without understanding, there is no meaningful advocacy and no motive for a culture of inclusion. And with that, your business or organization is left with a narrowed mission and weaker service because only some people are allowed at the table. Even Mother Nature knows that diversity makes the ecosystem stronger.

Day 100: WCAG and Motor Disabilities

Last official study day! I’ll continue to review my notes, WCAG, screen reader shortcuts, and work through Deque courses, but I will not feel obligated to post everyday after this. Summary of 100-day journey still to come.

A couple days ago, I covered WCAG and hearing impairments, so today I reviewed WCAG again to so how it benefits people with motor impairments that want to use the web.

Things I accomplished

What I reviewed

  • WCAG success criteria that benefit people with motor impairments;

What I learned from it

The following lists target WCAG success criteria that benefit people with motor impairments.

Level A

  • 1.3.2 Meaningful sequence
  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (v2.1)
  • 2.2.1 Timing adjustable
  • 2.2.2 Pause, stop, hide
  • 2.4.1 Bypass blocks
  • 2.4.3 Focus order
  • 2.5.1 Pointer gestures (v2.1)
  • 2.5.2 Pointer cancellation (v2.1)
  • 2.5.4 Motion actuation (v2.1)
  • 3.2.1 On focus
  • 3.2.2 On input

Level AA

  • 1.3.4 Orientation
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.4.5 Multiple ways
  • 2.4.7 focus visible
  • 3.3.4 Error prevention (legal, financial, data)

Level AAA

  • 2.1.3 Keyboard (no exception)
  • 2.2.3 No timing
  • 2.2.4 Interruptions
  • 2.2.5 Re-authenticating
  • 2.2.6 Timeouts (v2.1)
  • 2.5.5 Target size (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.5 Change on requesst
  • 3.3.6 Error prevention (all)

Day 98: WCAG and Hearing Impairments

Yesterday’s learning about how WCAG benefits people with visual impairments pushed me forward into more WCAG overview to see how it benefits people with hearing impairments (deaf and hard of hearing). Deafblind benefit from using the combined design techniques of visually impaired and hearing impaired.

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • links (WCAG 2.4.4, A & 2.4.9, AAA)
    • navigation between pages (WCAG 3.2.3, AA & 3.2.4, AA)
    • navigation on page
  • Navigation keyboard shortcuts for screen readers.
  • WCAG success criteria that benefit people with hearing impairments;

What I learned from it

Tips from Giles Colborne’s book Simple and Usable (as quoted in Web for Everyone:

  • simplicity is good science and good interface design
  • simple designs put complexity in its place
  • observe real people to learn what’s needed
  • designing for multiple devices supports accessibility

aria-describedby and aria-labelledby WILL access content that is inside a container hidden using aria-hidden="true".

aria-labelledby, aria-describedby, aria-label, and hidden text are some ways to let a screen reader user know of current page. Or use aria-current=”page” which has some support.

The following lists target WCAG success criteria that benefit people with visual impairments. The main concern for hard of hearing is to provide text or sign language alternatives to any sound provided.

Level A

  • 1.1.1 Non-text alternatives
  • 1.2.1 Audio-only & Video-only
  • 1.2.2 Captions (pre-recorded)
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.3 Sensory characteristics

Level AA

  • 1.2.2 Captions (live)

Level AAA

  • 1.2.6 Sign language (pre-recorded)
  • 1.2.8 Media alternatives (pre-recorded)
  • 1.2.9 Audio-only (live)

Day 97: WCAG and Visual Impairments

Yesterday’s learning about how WCAG benefits people with cognitive disabilities inspired me to look over WCAG again to see how it benefits people with visual impairments (blind and low vision).

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • page title (WCAG 2.4.2, A)
    • page and parts language (WCAG 3.1.1, A & 3.1.2, AA)
    • landmarks (WCAG 4.1.1, A)
    • headings (WCAG 1,3,1, A & 2.4.6, AA & 2.4.10, AAA)
    • links
  • Navigation keyboard shortcuts for screen readers.
  • WCAG success criteria that benefit people with visual impairments;

What I learned from it

The support among screen readers is better for the simple two-letter language codes (like “en” for English) than for the localized language codes (like “en-au” for Australian English).

Screen readers list forms only if marked as role="form" (the <form> element will be ignored in landmark lists).

The name of a link is calculated as follows (in order of precedence by screen readers):

  1. aria-labelledby
  2. aria-label
  3. Text contained between the opening <a> and closing </a> elements (including alt text on images)
  4. title attribute (note that this is considered a last resort method for screen readers to find something; it should not be considered a primary technique for giving names to links)

If headings have images, the alt text will be show up in the headings list. Linked images (whether HTML img or CSS background image) can be assigned aria-label or aria-described by. Spans can hide extra meaningful content for screen readers. All these alternatives make me wonder how that impacts people with cognitive disabilities or people who use speech recognition. It’s so important to design for more than one disability.

There are so many success criteria for this disability, compared to cognitive disabilities, but I imagine that’s because it is more objective and measurable. The following lists target WCAG success criteria that benefit people with visual impairments.

Level A

  • 1.1.1 Non-text alternatives
  • 1.2.1 Audio-only & Video-only
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.1 Info and relationships
  • 1.3.2 Meaningful sequences
  • 1.3.3 Sensory characteristics
  • 1.4.1 Use of color
  • 1.4.2 Audio control
  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (v2.1)
  • 2.2.2 Pause, stop, hide
  • 2.4.1 Bypass blocks
  • 2.4.2 Page titled
  • 2.4.3 Focus order
  • 2.4.4 Link purpose (in context)
  • 3.1.1 Language of page
  • 3.2.1 On focus
  • 3.2.2 On input
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions
  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

Level AA

  • 1.2.5 Audio description (pre-recorded)
  • 1.3.5 Identify input purposes (v2.1)
  • 1.3.4 Orientation (v2.1)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text
  • 1.4.10 Reflow (v2.1)
  • 1.4.11 Non-text contrast (v2.1)
  • 1.4.12 Text spacing (v2.1)
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.4.5 Multiple ways
  • 2.4.6 Headings and labels
  • 2.4.7 Focus visible
  • 3.1.2 Language of parts
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)
  • 4.1.3 Status messages (v2.1)

Level AAA

  • 1.2.7 Extended audio description
  • 1.2.8 Media alternatives (pre-recorded)
  • 1.3.5 Identify purpose (v2.1)
  • 1.4.6 Contrast (enhanced)
  • 1.4.8 Visual presentation
  • 1.4.9 Images of text (no exception)
  • 2.1.3 Keyboard (no exception)
  • 2.2.4 Interruptions
  • 2.4.8 Location
  • 2.4.9 Link purpose (link only)
  • 2.4.10 Section headings
  • 2.5.5 Target size (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.5 Change on request
  • 3.3.6 Error prevention (all)

Day 96: WCAG and Cognitive Disabilities

Even as I’m learning about design, it still comes down to me focusing more on people, their abilities, and the way they interact with the web. As usual, some learning leads to more questions, and more discoveries.

Things I accomplished

What I reviewed today

  • WCAG success criteria that benefit people with cognitive disabilities;
  • overview of ATAG, Part B (Authoring Tool Accessibility Guidelines):
    1. Fully automatic processes produce accessible content
    2. Authors are supported in producing accessible content
    3. Authors are supported in improving the accessibility of existing content
    4. Authoring tools promote and integrate their accessibility features
  • design considerations for various disability categories
  • accessibility-first mindset:
    • avoid exclusive design patterns
    • embrace diversity
    • create inclusive design

What I learned from it

The following lists target WCAG success criteria that benefit people with cognitive disabilities.

Level A

  • 2.5.1 Pointer gestures (v2.1)
  • 2.5.3 Label in Name (v2.1)
  • 2.5.4 Motion actuation (v2.1)
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

Level AA

  • 1.3.4 Orientation (v2.1)
  • 1.3.5 Identify input purposes (v2.1)
  • 1.4.10 Reflow (v2.1)
  • 1.4.12 Text spacing (v2.1)
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)

Level AAA

  • 1.3.6 Identify purpose (v2.1)
  • 2.2.6 Timeouts (v2.1)
  • 2.3.3 Animation from interactions (v2.1)
  • 3.1.3 Unusual words
  • 3.1.4 Abbreviations
  • 3.1.5 Reading level
  • 3.1.6 Pronunciation
  • 3.2.5 Change on request
  • 3.3.5 Help
  • 3.3.6 Error prevention (all)

Day 95: Designing an Accessible User Experience, Part 3

Today’s dedicated accessibility time was spent finishing walking through the topic of designing an accessible user experience, per continuation of Part 2.

Things I accomplished

  • Continued Deque’s “Designing an Accessible User Experience” course. 85% complete.
  • Continued reading A Web for Everyone. 8% complete.

What I reviewed today

  • Ability + Barrier = Disability;
  • Design + Accessibility = Inclusive Design;
  • UX for blind: audio-structural experience and interaction;
  • JAWS keystrokes (Insert + F3, Insert + Ctrl + R);
  • UX for deafblind: tactile-structural text-only;
  • UX for deaf: silent-visual;
  • Cognitive disabilities

What I learned from it

It’s usually best to keep the number of landmarks to a relatively short list, because part of the point of landmarks is to make it faster and easier to find things. The more landmarks there are, the less they help make things faster or easier

The most unique challenge for deafblindness is multimedia content. Solutions:

  • think text-first
  • create a simple design
  • use semantic structure
  • offer control over timing
  • use common words/phrases
  • apply screen reader techniques

WebVTT is one of the most versatile caption formats because users can set preferences like color, size, and font at system-level, which can trickle to browser-level.

WCAG 2.1 adds in some consideration for cognitive disabilities, but there is so much more to be considered, yet can’t be quantified as success criteria. Challenges to understand when considering a variety of traits under the cognitive disabilities category:

  • complex concepts
  • abstraction
  • sarcasm and satire
  • self versus others
  • problem-solving and critical thinking
  • speed
  • memory
  • attention
  • reading
  • speech and language
  • math
  • behavior
  • visual perception

Horton & Quesenbery constructed 9 design principles for incorporating accessibility into a website or application:

  1. people first: designing for differences
  2. clear purpose: well-defined goals
  3. solid structure: built to standards
  4. easy interaction: everything works
  5. helpful wayfinding: guides users
  6. clean presentation: supports meaning
  7. plain language: creates a conversation
  8. accessible media: supports all senses
  9. universal usability: creates delight

Best statement of the day

“The more you can think in terms of the semantic structure, the more successful you will be at creating a good user experience for screen reader users.”

Day 88: Presentation Prep – Humanizing People with Disabilities

Today I spent a lot of time preparing for a library conference talk about accessible spaces and being mindful of people with disabilities. So, rather than go into further study with Deque courses or deep-diving into accessibility laws (as originally planned), I decided to blog about the presentation I prepared for.

Things I accomplished

  • Compiled an outline and draft of slides for the presentation.
  • Interviewed three people about their disability.

What I reviewed today

My presentation is actually a co-presentation. Speaking alongside two other people, my part will specifically focus on the “who” of creating accessible workstations and spaces. Hopefully, the following outline will fit into a 15-minute time frame:

  1. What is a disability?
    1. Definition
    2. General categories
    3. Specific categories
    4. Specific disabilities
    5. Spectrums
    6. Related categories (elderly, environmental, temporary)
  2. Assistive Technologies & Adaptive Strategies
    1. Screen readers
    2. Magnification & zoom
    3. High contrast mode & custom styles
    4. Switch access and control
    5. Speech recognition
    6. Eye-tracking
    7. Augmentative and Alternative Communications (AAC)
  3. What is accessibility?
    1. Definition
  4. So, who are these people, anyway?
    1. Stephen
    2. Michael
    3. Chrissie
    4. How many Alaskans?
    5. Julie
    6. Tracy
    7. Me
    8. Who do you know?
  5. The point: They are people
  6. How can we be accommodating?
  7. Contact me

The overall intent of my talk is to humanize disabilities. What I really enjoyed about today’s preparation was the opportunity to talk with other people about their disabilities, and hear about the barriers they’ve encountered that made them feel disabled. The most fascinating part was that, out of the three people I interviewed, no one considered themselves disabled or having a disability. Only when they encountered a challenge or a complete roadblock did they consider themselves as having a disability.

Day 86: The point – it’s for people with disabilities, Part 2

A continuation of Part 1 as I work through the Deque courses and review who I am doing this work for.

Things I accomplished

What I reviewed today

Disabilities that I reviewed today through the Deque course:

  • deaf
  • deafblind
  • motor disabilities
  • speech disabilities
  • cognitive disabilities
  • reading disabilities
  • seizures
  • multiple disabilities

Deaf

How they may interact:

  • utilize captions and transcripts for video

Developer considerations:

  • offer transcript alongside an audio file (WCAG 1.2.1, 1.2.4)
  • offer captions alongside video with audio (WCAG 1.2.2, 1.2.9)
  • when possible, offer sign language with videos with audio (WCAG 1.2.6)

Review Day 55: Users with Auditory Disabilities.

Deafblind

How they may interact:

  • interacts with keyboard (QWERTY or braille)
  • receives information through refreshable braille display and screen reader software

Developer considerations:

  • content needs to be text or coupled with text equivalents (WCAG 1.1)
  • site functionality must work with a keyboard (WCAG 2.1)
  • markup must be structured well, using appropriate semantics (WCAG 1.3, 2.4, & 4.1.1)
  • custom elements must express themselves with a name, role, and value (WCAG 4.1.2)
  • dynamic changes in content comes with an alert for screen readers (WCAG 4.1.3)
  • videos need audio description if the audio is confusing by itself (WCAG 1.2)
  • active controls need to be clickable (WCAG 2.5)
  • offer transcript alongside an audio file (WCAG 1.2.1, 1.2.4)
  • offer captions alongside video with audio (WCAG 1.2.2, 1.2.9)
  • when possible, offer sign language with videos with audio (WCAG 1.2.6)

Motor disabilities

Motor disabilities includes a wide spectrum of varying degrees and characteristics of physical experiences, challenges, and strategies. Specific disabilities include: cerebral palsy, ALS, quadriplegia, or missing limbs. Review Day 54: Users with Motoric Disabilities.

How they may interact:

  • mouth stick on keyboard (vertical or horizontal)
  • adaptive keyboard (one-handed, expanded, raised keys, etc.)
  • switch control devices
  • speech recognition software
  • eye tracking software

Developer considerations:

  • site functionality must work with a keyboard (WCAG 2.1)
  • interactive components (links, buttons, input) need a visible focus and hover state (WCAG 1.4.13)
  • warn users about time outs ahead of time, and offer extension of time (WCAG 2.2)
  • mark interactive controls large clickable targets (WCAG 2.5.5)

Speech disabilities

The causes of speech disabilities range from learning, motor, or auditory disabilities, autism, brain injury, stroke, cancer. They may or may not have full use of their voice and how they use that voice. Some issues can be categorized as stuttering, cluttering, apraxia, dysarthria, speech sound disorders, or non-vocal.

How they may interact:

  • unaided augmentative and alternative communication (AAC): body language expressions, gestures
  • aided augmentative and alternative communication (AAC): pen & paper, boards with symbols, speech-to-text software

Developer considerations:

  • provide other input methods other than voice input (WCAG 2.5.6)

Cognitive disabilities

Cognitive disabilities cannot be easily defined due to its wide spectrum. Some characteristics may include: limited comprehension, low tolerance for cognitive overload, limited problem-solving skills, short-term memory loss, attention deficit, difficulty reading, and difficulty understanding math. Review Day 53: Users with Cognitive Disabilities. It is the most common disability, due to its wide spectrum.

How they may interact:

Developer considerations:

  • create a simple interface (WCAG 1.4.8, 1.4.12)
  • write clear, direct, and easy to understand content, which includes a mixture of images and text (WCAG 3.1, 1.3.3)
  • post shorter videos and audio tracks
  • limit the number of choices offered at one time
  • offer help features (WCAG 3.3.5)
  • design for ease of use
  • test for usability with actual users with this disability
  • strive for consistency of information, navigation, and landmarks across the website (WCAG 3.2.3, 3.2.4)
  • reduce or allow control of distracting elements (motion, animation, autoplay) on a page 2.2.2)
  • warn users about time outs ahead of time, and offer extension of time (WCAG 2.2)
  • avoid use of Captcha

Reading disabilities

This could be caused by a cognitive disability or an another underlying reason. Review Day 52: Users with Reading Difficulties.

How they may interact:

  • customize foreground and background colors
  • customize typography
  • listen to text with a screen reader
  • use a screen reader for highlight text to follow along

Developer considerations:

  • include a mixture of images and text to convey the same information (WCAG 3.1, 1.3.3)
  • use good color contrast, but avoid the highest level, like black on white (WCAG 1.4.3, 1.4.6)
  • provide flexibility of user customization of styles for text and background (WCAG 4.1.1)

Seizures

How they may interact:

  • reduce animation and pause or skip video

Developer considerations:

  • avoid using video, transitions, and animations with frequent intense flashing (WCAG 2.3)

Multiple disabilities

A person deals with two or more disabilities.

How they may interact:

  • see all considerations under blind, low vision, deaf, deafblind, motor disabilities, speech disabilities, cognitive disabilities, reading disabilities, and seizures

Developer considerations:

  • see all considerations under blind, low vision, deaf, deafblind, motor disabilities, speech disabilities, cognitive disabilities, reading disabilities, and seizures

Day 85: The point – it’s for people with disabilities, Part 1

“…if you don’t understand the challenges that people with disabilities face when using ICT products and services, you don’t really know accessibility. Knowing what challenges people face is central to knowing how to reduce or eliminate challenges.” Karl Groves, What does it take to call yourself an accessibility expert?

That about sums it up for me after working through the WAS Body of Knowledge. The only way one can evaluate websites well is to remember who could be using our sites and how their engagement and experience may differ from our own. That’s basic UX (user experience) design, but with a focus on users with disabilities, which still encompasses a wide range of people and engagement strategies.

Things I accomplished

What I reviewed today

I’m trying to bring my focus back to the “who” part of my training. Without keeping them in the front of my mind, I will not be able to properly advocate for accessibility. Deque’s course highlights the following disabilities:

  • blind
  • low vision
  • color-blind
  • deaf
  • deafblind
  • motor disabilities
  • speech disabilities
  • cognitive disabilities
  • reading disabilities
  • seizures
  • multiple disabilities

Today I read through their explanations about various visual impairments. I found it helpful to revisit things I learned about in the past about users with low vision and identifying issues for keyboard users.

Blind

How they may interact:

  • may navigate by headings, landmarks, links via screen reader software;
  • listen for title and structure details of page via screen reader software;
  • use screen reader software, keyboard, refreshable braille display, touchscreen, or voice commands for input or output

Developer considerations:

  • content needs to be text or coupled with text equivalents (WCAG 1.1)
  • site functionality must work with a keyboard (WCAG 2.1)
  • markup must be structured well, using appropriate semantics (WCAG 1.3, 2.4, & 4.1.1)
  • custom elements must express themselves with a name, role, and value (WCAG 4.1.2)
  • dynamic changes in content comes with an alert for screen readers (WCAG 4.1.3)
  • videos need audio description if the audio is confusing by itself (WCAG 1.2)
  • active controls need to be clickable (WCAG 2.5)

Low Vision

Low vision is a spectrum. It varies in degrees and characteristics.

How they may interact:

  • magnify the entire screen (with magnification software), zoom into web pages, or increase text size
  • increase contrast or invert colors with High Contrast Mode or other software
  • use screen reader to hear text
  • navigate by keyboard or mouse

Developer considerations:

  • popups, alerts, and errors should be close to the visual focus
  • color should not be the only way to relay important information (WCAG 1.4.1)
  • contrast of foreground and background should be no less than 4.5:1 (WCAG 1.4.3, 1.4.6, 1.4.11)
  • don’t disable pinch-to-zoom
  • interactive components (links, buttons, input) need a visible focus and hover state (WCAG 1.4.13)
  • controls need to look different (actionable) than text (WCAG 1.4.8)

Color-blind

This is not an either-or characteristic either. Degrees of color identification vary from person to person.

How they may interact:

  • strategies to compensate may involve asking for help to distinguish colors

Developer considerations:

  • color should not be the only way to relay important information (WCAG 1.4.1)

Day 82: Testing with Users with Disabilities

Today’s study session led me back to usability testing. This seems to be critical when it comes to adding it to our testing toolbox to check for usability and accessibility issues that escape conformance checks, alongside automated and manual testing tools.

Personally, this is one of the areas I struggle with implementing. I love reading about usability testing and case studies that people document, but I’ve not yet taken the opportunity to try doing this myself. Usually because it has it’s own added cost, as well as awkwardness to set up testing with a specific group of people. Maybe this will be my motivator to make some connections and start a plan to make this happen this year.

Things I accomplished

Read:

What I learned today

The guidelines are not all-inclusive. Some good accessibility techniques may not be in WCAG because:

  • It is difficult to objectively verify compliance with the technique
  • The writers of the guidelines did not recognize the need for the technique when writing the guidelines.
  • The technique was not necessary (or at least not anticipated) at the time the guidelines were written, because the technologies or circumstances that require the technique are newer than the guidelines.

Before bringing in users for testing, do some preliminary checks and fix known issues in order to better discover underlying accessibility and usability challenges that were not detectable by software or manual checks.

Including users in testing doesn’t have to be a full-blown usability study. Informal evaluations and brief interactions with feedback can be very helpful. Additionally, informal evaluations can happen throughout the product’s lifecycle, rather than formal usability studies that usually occur near the end of development. Bonus: informal interactions can help us all see the person clearer rather than a case study.

Never assume that feedback from one person with a disability speaks for all people with disabilities. A small-scale evaluation (only a few people within a study) is not enough to draw solid conclusions with statistical significance, even though valuable insight occurs. Try to include a variety of disabilities: auditory, cognitive, neurological, physical, speech, and visual with different characteristics. If possible, include older people, as well.

Further reading

 

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.