Types of Disabilities, Part 2

In Types of Disabilities, Part 1, I learned and shared about visual, auditory, and mobility disabilities. In this post I’ll cover the rest of the list, diving deeper into the the categories covered by the Deque material and CPACC Body of Knowledge: cognitive, speech, seizure, psychological, and compound.

Cognitive

Cognitive disabilities are the most common type of disability due to its broad definitions, which include impairments in thinking, language, learning, perception, attention, memory, and problem solving.

Types of cognitive disabilities:

  • Neurodevelopmental disorders (autism, Down’s syndrome)
  • Memory impairments (Alzheimer’s, dementia)
  • Neurodegenerative disorders
  • Brain injury impairments (injury, tumors)
  • Learning disabilities (dyslexia, dysgraphia, dyscalculia, aphasia)

Causes of cognitive disabilities:

  • congenital
  • developmental
  • traumatic injury
  • infections / disease
  • chemical imbalances
  • aging

Suggested AT or strategies for improving focus, leveraging learning styles, or accommodating short-term memory:

  • screen magnifier
  • easily editable/customizable content
  • customizable fonts and colors
  • screen reader or speak aloud
  • interactive transcripts
  • blocking animations or flashing elements
  • break up long tasks by saving work and doing shorter tasks

Additional reading about cognitive disabilities:

Digital Environments
Challenge Solution
Complex designs
  • Designers can create simple, predictable, organized designs
Complex tasks
  • Simplify steps or user components
Technical problems and errors
  • Alert about errors
  • Provide clear solutions
Physical and Digital Environments
Challenge Solution
Text-based information
  • Supplement with images and visuals
  • Use simple and easy-to-understand language

Reading (dyslexia, dysgraphia)

Digital Environment
Challenge Solution
Floating words
  • Font for Dyslexia
  • Additional time to complete tasks
Letter confusion, such as p b d q
  • Font, contrast, style customization
  • Additional time to complete tasks
Timed sessions
  • Time extensions or saved work during timeouts
  • Screen reader to listen along with text or view highlighted words or phrases
  • Visible focus indicators to keep track of their position on the page
  • Applications or dictionaries that present words with pictures
  • Additional time to complete tasks
Deciphering the way content is presented
  • Custom style sheet
CAPTCHA
  • Alternate type of security feature or problem to solve
Difficulty processing visual content
  • Screen reader to listen to content
  • Additional time to complete tasks
Difficulty accurately spelling words
  • Spelling and grammar checkers

Additional Reading:

Math (dyscalculia)

People with dyscalculia have difficulty understanding or using math based on how their brain functions, as opposed to experiencing a psychologically-induced fear.

Digital Environments
Challenge Solution
Distinguishing right from left in graphic images
  • Data table or text description
  • Additional time to complete tasks
Graphs, figures and diagrams (difficult to copy)
  • Text-to-speech to listen to problems
  • Additional time to complete tasks
Calculations
  • Reference sheet with common equations, as an accommodation
  • Onscreen calculator, as an accommodation
  • Additional time to complete tasks

Speech

A person with a speech disability may have trouble articulating words or producing speech sounds. Often times people with speech disabilities will use unaided or aided Augmentative and Alternative Communication (AAC) to give them a voice. A person with a speech disability may or may not have additional disabilities. In that case, the same design considerations for blindness, low vision, motor disabilities, auditory disabilities, and cognitive disabilities may need to be used.

Causes of speech disabilities:

  • genetics
  • learning disabilities
  • auditory disabilities
  • motoric disabilities
  • autism
  • traumatic brain injury
  • stroke
  • cancer

Some types of speech disabilities include:

  • stuttering
  • cluttering
  • apraxia
  • dysarthria
  • speech sound disorder (articulation, phonetic)
  • muteness

Suggested AT or strategies for people with speech disabilities:

  • touch screens
  • alternative keyboards
  • single switch devices
  • eye-tracking technologies
  • speech-generating software
  • word prediction software
  • symbol boards and languages
  • symbol software
  • translation software
Digital Environments
Challenge Solution
Live chats / webinars / teleconferences (voice-based communication)
  • offer text-based chat
Additional disability (low vision, hard of hearing, etc.)
  • create interoperable content for optimal accessibility;
  • captions & transcripts;
  • keyboard operable;
  • multiple formats of content
Physical Environments
Challenge Solution
May have mobility issues
  • same solutions for motoric disabilities
Additional disability (low vision, hard of hearing)
  • create interoperable content for optimal accessibility
  • captions & transcripts
  • keyboard operable
  • multiple formats of content
General
Challenge Solution
producing speech sounds
  • low-tech AAC (boards, gestures);
  • high-tech AAC (computer-generated voice);
  • patience

Additional resources:

Seizure Disorders

Seizures are electrical impulses in the brain that can interfere with information processing or create involuntary muscle movement. Photo-epileptic is one type of seizure.

Causes of seizures:

  • brain injury
  • dehydration
  • sleep deprivation
  • infections
  • fevers
  • drug overdoses or withdrawals
  • flashing lights (photo-epileptic)
Digital Environment
Challenge Solution
intense flashing light, blinking, or flickering
  • eliminate or reduce speed/intensity of flashing/animation

Psychological/Psychiatric

Psychological disorders encompass a wide range of emotional and mental conditions. When the condition impacts daily life activities, it becomes a disability. Some causes of mental illness may include:

  • trauma
  • chemical imbalances
  • genetics
  • social factors

Anxiety

Anxiety disorders are the most common of psychological disorders. This disorder manifests itself as fear and worry about situations or objects. A few anxiety disorders are:

  • panic disorder
  • phobias
  • post-traumatic stress disorder (PTSD)
  • obsessive-compulsive disorder (OCD)

Mood

Mood disorders create mood fluctuations in that person. Some subcategories of mood (affective) disorders:

  • depression
  • bipolar
  • seasonal affective disorder (SAD)

Schizophrenia

Schizophrenia is broken into two groups: positive (hallucinations and delusions) and negative (lack of motivation, dreary mood, isolating). It’s theorized that this disorder is caused by either genetics, chemical imbalance, or environmental factors. Sometimes people with this disorder can struggle with:

  • expressing themselves
  • attention and memory deficits
  • controlling their movements.

It’s estimated that 2.4 million (1.1%) Americans have schizophrenia. It’s also estimated that 4.9% of people with schizophrenia commit suicide with the average age of the life lost being 28.5 years old.

Additional Resources about Schizophrenia:

Other Psychological Disorders

Attention Deficit Hyperactivity Disorder (ADHD)

ADHD is categorized as a behavioral disorder. It’s broken up into 3 subcategories: inattention, hyperactivity, and impulsivity.

Personality Disorders

Personality disorders are when people’s behavior deviate from cultural expectations. Two common personality disorders are antisocial personality disorder and borderline personality disorder.

Eating Disorders

Eating disorders cause concern over food and weight. The 3 most common eating disorders are anorexia nervosa, bulimia nervosa, and compulsive (binge) eating.

Multiple/Compound

It’s possible to have more than one disability. People with multiple disabilities may experience a combination of disabilities (of different degrees) that affect their speech, motor, visual, or hearing abilities. More inclusive accommodations help anyone with multiple disabilities to live life more independently.

In Conclusion

Without understanding the people within this multifaceted culture of disability, we can’t create solutions to the challenges they face. Read my other posts from my WAS journey that go further into keeping perspective about the people we are trying to include and serve:

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.

6 Theoretical Models of Disability

In my last post Basic Disability Concepts, I mentioned that we all need a perspective check when we design websites and start thinking about people with disabilities. Turns out that there are many different theoretical models that have been proposed on this very topic of how we perceive disabilities! I’ve encountered a couple of these before, thanks to Sarah Horton’s and Whitney Quesenbery’s book A Web for Everyone (Amazon).

The models I cover in this post:

  1. medical,
  2. social,
  3. economic,
  4. functional solutions,
  5. social identity, and
  6. charity.

There are more than 6 models that have been theorized, but I only offer them a mention, and provide resources at the end to get you started on your own research.

Medical

The medical model (perspective) views disability as a medically-diagnosed biological problem due to genetic disorders, disease, trauma, or other health conditions. Law leans this definition to critically evaluate whether a person is impaired “enough” to receive benefits or accommodation. The person has a problem that needs to be cured or fixed.

Strengths:

  • emphasizes the biological
  • offers criteria for medical treatment and legal evaluation
  • belief that a compassionate society will invest in health care and services to support disabilities

Weaknesses:

  • overlooks impact of design decisions (it’s the person’s problem, not the environment)
  • stigmatizes people as different or second-class citizens
  • can create narrow and exclusive definitions
  • dehumanizing if a person has to prove their disability

Social

The social model (perspective) views disability as a condition created by bad design. Society’s ecosystem institutes barriers for people. It’s in response to the medical model, and rallies for change in the culture and ideology of society to be more inclusive.

Strengths:

  • emphasizes the human right to participate in society
  • removes stigma
  • inspires creative design

Weaknesses:

  • de-emphasizes biological reality of a disability
  • strips disability from a person’s identity

Economic

The economic model (perspective) views disability as the inability of a person to work and contribute to society. It’s related to the Charity/Tragedy model.

Strength:

  • emphasizes the need for economic support or accommodation

Weaknesses:

  • disabled become stigmatized as needy
  • narrow definition may deny help to a person who needs it but doesn’t meet qualifications

Functional Solutions

The functional solutions model (perspective) views disability as problem to be solved. Specifically, it seeks to overcome physical limitations with technology. It cares less about the social or political nuances, but rather strives for innovation as its motivation. Accessibility professionals often live in this space.

Strengths:

  • meets people where they are
  • service-based
  • focused on solutions
  • real-world approach

Weaknesses:

  • myopic (doesn’t address broader issues)
  • misses opportunities of social change

Social Identity / Cultural Affiliation

The social identity or cultural affiliation model (perspective) views disability as a community. People who identify with a particular group or culture (e.g. deaf culture) become more involved with that culture and embrace their disability as part of their identity.

Strengths:

  • disability is accepted and even a point of pride
  • groups find political strength to advocate for change

Weaknesses:

  • sense of exclusion when a person doesn’t fit the mold or expectation of the group
  • alienation from society when involved with a specific group

Charity/Tragedy

The charity or tragedy model (perspective) views disability as tragic, unfortunate, or inspirational. When this perspective becomes an attitude, it can become offensive to people with disabilities.

Strength:

  • inspires fundraisers, projects, assistance, and intervention for people with disabilities

Weaknesses:

  • creates an unhealthy social relationship or hierarchy
  • condescending or dehumanizing
  • perpetuates the lie that people with disabilities are objects of inspiration (inspirational porn)
  • short-term

Other Models

In addition to the models I’ve dissected in this post, there were other honorable mentions in the CPACC coursework I’m working through; all of which have their own merits and pitfalls.

  • Affirmation: similar to the social identity model, it views disability as an chance to affirm one’s identity and celebrate that part of self;
  • Sociopolitical: views disability needs as a human right;
  • Religious/moral: views disability as an act of God to punish or teach;
  • Expert/professional: a variation of the medical model, it views disability as a condition to be treated or managed by experts;
  • Rehabilitation: a variation of the medical model, it views disability as a condition to be treated be therapy and rehabilitation;

Are you familiar with any other models that haven’t been mentioned here?

Where Do You Stand?

I don’t know about you, but all these models have given me a lot to think about, challenging my own perspective and world view. The variety of definitions have offered some confirmation on thoughts I’ve had. In contrast, they’ve pointed out some of my own fault in thinking about myself and others.

In order to do the work of advocating for people with disabilities and developing websites with accessibility in mind, we need to understand our own point of view. Believe it or not, our work is colored by our current perspective. Before we can have conversations with people with disabilities, we need to evaluate where we stand and what language we use.

What does “disability” mean to you?

Resources I Found Helpful

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.

CPACC Exam Preparation Begins

It’s happening, as I hoped it would. As I mentioned in my last post about passing the WAS exam, my intention following that certification was to move forward and take IAAP’s Certified Professional in Accessibility Core Competencies (CPACC) certification exam. I’m looking hard at their Certified Professional in Web Accessibility (CPWA) credential, which happens when both the CPACC and WAS exams have been passed. I’m halfway there, and want them all acquired by 2020.

Unlike the 100 days that I spent studying for WAS, I’m less stressed about this next exam, even though it’s stepping outside of my role as a developer. This past year and a half, I’ve been overseeing an accessibility audit at my place of employment, and now carry the torch of educating and enforcing web and digital accessibility. I feel there is a lot of value in firming up my knowledge of the “core competencies” of accessibility. My last journey opened up many opportunities to advocate for accessibility, and I’m hoping this journey will be no exception.

Just as IAAP’s WAS certification offered me a roadmap to learn the processes and technicalities of web accessibility, I’m trusting that their CPACC Body of Knowledge combined with Deque’s CPACC Certification Preparation will afford me the same confidence. I want to keep moving forward in accessibility and teaching others about it. This is the best way I know how.

My roadmap

So, here’s my plan. I’ve applied to take the CPACC on December 18, and my application was accepted. That gives me 6.5 weeks to work through Deque’s coursework, and fill in any gaps in knowledge I may have. It feels like a tight study window, but I also think that I over-studied a bit for WAS, so some sections look like review to me. In hindsight, I can see why CPACC is recommended as the first certification to earn. It focuses a lot on people and reasoning about accessibility. However, not knowing how far I’d get in my journey, taking WAS was my best bet for success at that point in time.

Anyway, back to the rest of my plan. I’ve perused the CPACC coursework I’ll be doing, and I’ve managed to work out how I can fit it into those 6.5 weeks. (Disclaimer: Don’t replicate my time frame, if you’re taking the CPACC as your first certification and have little working background in accessibility; give yourself more time.) My plan is to divide up the 14 sections presented in Deque’s coursework, as follows:

  1. Week 1: Basic disability concepts; Theoretical models of disability.
  2. Week 2: Types of disabilities.
  3. Week 3: Disability stats; Disability etiquette; Benefits of accessible design.
  4. Week 4: Web accessibility principles; Universal design for the web.
  5. Week 5: Universal design for the physical world; Universal design for learning; Usability & accessibility.
  6. Week 6: Myths and misconceptions about accessibility; Accessibility law.
  7. Week 6.5: Organizational governance & management.

Each section has its own set of subsections that vary in number and length. I’ve chosen to group sections together based on some of the knowledge I have already, and what I anticipate to take longer or shorter amounts of my study time. Like my 100-day WAS journey, I’ll be dedicating an hour a day to study. I want to allot enough time to truly learn and not breeze over important ideas and principles. Additionally, I’d like to tap into other online resources as I go through these concepts each week, as well as comparing the Body of Knowledge with the coursework.

Going forward

Honestly, I keep wavering back and forth between blogging on a daily or weekly basis. I don’t want blogging to get in the way of achieving my goal in a such a short time frame, and yet I anticipate that some study days will present so much information that I can’t help but write it down to share immediately. I’m talking about a difference between 7 and 45 posts here. Ultimately, I’ll tweet every day as I learn something new or want to share important ideas. So, if you’re interested in when I do post, I’d subscribe to this blog in order to have those updates pushed to you during whatever time frame I settle on as I progress. Or follow me on Twitter, if that’s your preferred news feed.

Going forward, today is the official start of my study preparation for the CPACC exam. It’s going to be a busy month and a half. Wish me luck.

I Passed!

A little over 6 weeks (mid-May) after sitting for the WAS exam (early-April), I received an e-mail congratulating me on passing the Web Accessibility Specialist certification exam, established by the International Association of Accessibility Professionals (IAAP). WOW! That truly made my day. Not only had I passed, but I did well with a score of 729 on a scale of 100-800. I was excited and reassured that I did understand web accessibility after putting in the time to study.

It was over 2 years ago that I started this journey of learning about web accessibility and exploring the POUR principles (Perceivable, Operable, Understandable, Robust) by the World Wide Web Consortium (W3C). Even back then, I had challenged myself to spend 100 consecutive days trying to glean from professionals and online documentation. Let me tell you, it was slow going then, and I felt as though I hardly got anywhere. This second 100 days was different. I had a goal and an outline to go by.

After discovering IAAP’s WAS certification and their Body of Knowledge document outlining what technicalities a web accessibility consultant should know, I was going big or going home. OK, I wasn’t going to quit if I didn’t earn their certification, but I would have doubted my own abilities and understanding. Anyhow, I convinced my employer to support my endeavor by financing my exam and allowing me to spend some work time on a weekly basis to study.

100+ days of self-directed study, working through Deque’s WAS certification courses, asking questions to experts, and practicing coding techniques and evaluation concepts truly paid off when it came to achieving my goal. Upon receiving my results, I felt like I may have over-studied for the exam, but walked away with a richer experience and knowledge-base than was expected of me. I had no regrets.

Special thanks to so many who helped me get this far:

  • IAAP for giving me a goal line and a clear pathway to get there,
  • the Alaska State Libraries, Archives, & Museums for supporting my continuing education,
  • the State of Alaska webmasters and our ADA coordinator who inspired me to find answers to all our pressing accessibility questions,
  • my friends with disabilities who humored my questions and opened up to me about barriers they encountered, which motivated me to do better,
  • my family for being supportive and understanding that this is something I needed to spend time on at home,
  • Deque University for awarding me a scholarship, enabling me to take their courses, and
  • the Twitter, Slack, and LinkedIn web a11y (accessibility) communities for answering my questions and cheering me on; there are just too many names to mention without leaving someone out!

If you’re just starting your own journey into accessibility and feel overwhelmed or confused, don’t be. There’s a whole community of people willing to help, guide, and cheer for you! And the fact is, we are all still learning because there is no real one-size-fits-all way of writing code and crafting experiences. You can do this. Stay motivated, understanding that the more you know and practice, the more you’re helping build a better web for everyone.

Learn from me, but go beyond me. Talk to experts. Talk to people with disabilities. Experiment on your own. Put what’s new to you into practice as often as you can. And, most of all, believe in yourself and the mission to enable more people to equally use the web.

I am now Amy Carney, Web Accessibility Specialist, and I am still learning, too. Web accessibility is one of my passions, so contact me if you have web accessibility questions, want to share your own story, or are looking for a presenter for your conference or meetup. In the meantime, I’ll continue to build upon my own learning and credentials by preparing for IAAP’s CPACC certification, and educating others when the opportunity arises.

A reflection on my 100 Days of A11y

One week ago I sat for IAAP’s (International Association of Accessibility Professionals) Web Accessibility Specialist (WAS) certification exam. After 200+ hours of self-guided study, spanning over 100+ days — through sickness and in health — plus 13 Deque prep courses, I met the exam head-on with optimistic yet nervous energy. Would the studying and coursework be enough to pass? Had I actually learned the core principles and technicalities that would allow me to answer confidently and feel as though I qualify as a specialist?

I can’t say for certain if I passed because it takes 4-6 weeks for me to hear back on the pass or fail result. However, I can say with certainty that all of this was not a total fail. I put in the time to learn in-depth about web accessibility principles, guidelines, and technical specifications. I took several chances to teach others about web accessibility. Additionally, I was inspired to keep advocating for accessibility and continue learning so I can create better experiences for people on the web.

Why did I do it?

This is one of the first questions people ask me after they heard about my desire to take the exam or the 100 days I committed to pursue web accessibility knowledge. To this, my reply was simply, “because I want to learn web accessibility at a greater depth than I what I know now. This exam gives me study materials and a goal post.” To add to that, I’ve learned from my two rounds of 100 Days of Code that I could learn a lot and accomplish much if I’m accountable throughout a 100-day period. That type of commitment forced me to be systematic and pushed me into forward motion.

As a matter of fact, Nicolas Steenhout interviewed me about it on his A11yRules podcast:

  1. E76 – Interview with Amy Carney – Part 1 (26 minutes)
  2. E77 – Interview with Amy Carney – Part 2 (16 minutes)

How did I do it? A timeline.

No journey is complete without some sort of pre-planning and external support. My planning began with garnering support and acquiring permission to spend time on this project with the return on investment being improved accessibility for their sites, as well as sharing the knowledge statewide. On November 28, 2018, I approached my boss about taking the WAS exam with the support of my division behind it. It didn’t take long to get his approval, as well as our director’s approval.

Based on that approval, I started Day 1 of my Web Accessibility Specialist journey on November 30, 2018 with the intention to take the exam on April 3, 2019. That plan would allow me four whole months of self-guided study, and address any bumps that may come up along the way. Every single day (except for Christmas Day), I spent 1-2 hours of my time either reading articles, watching videos, delving into documentation, or picking apart accessible code. Each of these were all discovered by using the WAS Body of Knowledge [Word doc] as my guide for topics to explore. Alongside my studying, I took time to journal (blog) each day to keep myself accountable and share with others the discoveries I’d made, hence the very existence of the 100 Days of A11y website you are pulling this article from.

On February 21, 2019, in the midst of my self-guided study, I was awarded a year’s membership to Deque University. This gave me access to all their courses, which included the thirteen courses that would prepare me for the WAS certification exam. Within a few days of enrollment, I started working through the pertinent courses with intention to work through all thirteen in order to fill in any gaps, plus act as review for what I’d already learned.

It wasn’t until February 22, 2019 when I finally finished working through the WAS Body of Knowledge. By that time I’d gotten a good handle on the Web Content Accessibility Guidelines (WCAG), discovered the Authoring Tools Accessibility Guidelines (ATAG) for the first time, and revisited the Accessible Rich Internet Applications (ARIA) specification and its recommended practices. Additionally, I had the opportunity to try out new code by creating accessible JavaScript components and create an evaluation report about a website’s accessibility.

On March 3, 2019, I began reading A Web for Everyone by Sarah Horton and Whitney Quesenbury. Though this was by my own choice and interest, rather than a recommended read from a list, it greatly benefited me at this point in my journey. The points they really brought home about the people we design for and the experiences we build were perfect timing. Each idea for inclusive design was well-received, thanks to the knowledge about WCAG and people with disabilities that I’d built up prior to entering into their text.

It was on March 10, 2019 that I completed my 100 days of self-guided study for the WAS exam. For the next 5-6 days I took a break from such a time-consuming commitment. That break period allowed me to take advantage of some sunny weather with my family before diving full-force into the Deque courses that still lay ahead.

April 2, 2019, the day before my exam, I finished the final course on Deque that I needed in order to feel more prepared for the WAS exam. It was a long course, but ever-so-necessary, since it reinforced what I needed to know about testing sites for accessibility.

At last, exam day had arrived. On April 3, 2019, I sat for the exam with my designated proctor. In under an hour, I was able to answer all 75 questions, some of which I may have missed. I walked away with much relief, mixed with a sense of affirmation that I had indeed learned something over those last four month. To me, it had all proven to be a success.

What did I take away from all this?

People are the reason

As I mentioned in one of my journal posts, the point of all of this comes down to people. Accessibility is specifically aimed at people with disabilities. Without that core understanding, the resources I tapped into would have been un-relatable and useless. The biggest thing I gained from this was the expansion of my perception. My accessibility mission starts first with understanding who is accessing the web and how they may interact with it. It’s important for me to grasp that we do not all share the same contexts, environments, and experiences. Nor do we all respond the same way to the same website.

Resources are ripe for the Googling

Over two years ago when I was digging around the Internet, trying to figure out were to start on web accessibility with only WCAG in mind, I felt so lost. I think that was partly due to the fact that I found some websites very unfriendly and uninviting. Any time I googled “WCAG” it brought me to the normative documentation or the Web Accessibility Initiative (WAI) site. Both made me leave rather quickly.

That being said, I am happy to report that several things have changed since then, and more homegrown contributions have popped up on the web. For one, the WAI website‘s recent redesign is so much more inviting to someone like myself. Additionally, I’ve found a whole community on Twitter that hashtags accessibility (#a11y). Those people led me to personal blogs or other people’s articles and online talks, including Inclusive Design 24 and A11ycasts on YouTube. Later, I was able to join a Slack group centered on dedicated topics of web accessibility. All of these things have been fabulous, informative, and inviting. I am grateful that so many conversations and open knowledge-sharing is happening online that I can partake in or at least lurk around to listen.

Web accessibility is no different than any other part of front-end development. We can’t possibly memorize every single detail. The critical part comes down to building up the right toolbox for ourselves, and bookmarking the resources that we need to consult often.

Don’t re-invent the wheel: use code examples

To fill up that toolbox, look back at the resources that I tapped into, which were also generous in offering up code examples. What’s one thing we designers and developers crave the most when learning accessibility? Code snippets! We want to see how someone else successfully made their component or pattern accessible in real life. I like to play with code and try to build things creatively myself (as do many of us), but I also draw comfort from knowing others have worked on this and found a good solution that provides an equal experience for a wider audience.

Thank you to anyone who has unabashedly shared what they’ve learned and how they made it work. Your HTML, CSS, and JavaScript are much appreciated.

Also, I should mention ARIA as being relevant to my code endeavors and improvements, since I was forced to learn much of it during my self-guided study and Deque courses. It was the kick in the pants I needed to dig deeper into it’s documentation suite and get to know it’s full use and purpose. ARIA can still feel a bit complicated, but at least I understand it so much more than I did four months ago.

Testing and evaluation are a necessary skill

Not only have people offered up their code snippets, but some dedicated individuals have also presented what they’ve found when testing on specific platforms and user agents (browsers) with various assistive technology. This is truly the step forward that I think people like myself have been missing out on.

Studying for the WAS exam really pushed me forward in this area. It’s a skill, and it’s an important one. As someone who is deeply invested in providing a good user experience (for everyone), I was lacking in full understanding of how to test the sites I was building or maintaining. The WAVE toolbar and other automated tests were just not enough. The WAS Body of Knowledge not only made clear that I needed a fuller understanding of testing tools, but also that I needed evaluation methodologies, which I was completely clueless about beforehand. Thanks to their suggested list of various testing tools and techniques and WCAG-EM, I feel a lot better equipped to scrutinize each experience I’m providing to the public. It’s become part of my own workflow in design and development now.

I can’t turn back

It’s too late for me. I’ve swallowed the red pill and now I can’t go back to living in blissful ignorance and the illusion that everyone can easily use the sites I make. No longer can I be happy with un-semantic HTML elements, poor CSS design choices, and it-works-with-my-mouse JavaScript. To make matters worse, I may be alienating myself because I can’t help but bring it up and point out current problems. My Twitter feed is a prime example of my web accessibility knowledge and opinions running over a once placid profile. If that’s too overwhelming, you could ask my co-workers about me, but you’re bound to hear the word “accessibility” in that conversation.

What exactly is a Web Accessibility Specialist, again?

The WAS Body of Knowledge says that to be considered a Web Accessibility Specialist, one must understand how to:

  1. create accessible content, using WCAG, ARIA, and ATAG,
  2. identify accessibility issues, utilizing manual and testing tools, and
  3. remediate accessibility issues by offering evaluation and reports.

But what about assumptions we make when deeming who is an expert and who is not? For instance:

  • Can she recite any WCAG success criteria by number when quizzed?
    Maybe, if she spends every day evaluating with those success criteria.
  • Does she have every ARIA pattern memorized, ready to compare on examination of another’s source code?
    It’s possible. A few people are code geniuses.
  • Are all screen reader keystrokes memorized and performed fluidly by this alleged specialist?
    Doubtful, but some native screen reader users might be apt at this.
  • Will her site evaluation and report say the same thing another specialist’s report says?
    Unlikely, but miracles do happen.

Is a certification necessary? Maybe so or maybe no. In short, I think that IAAP is on the right track. There are a lot of things to understand, know, and consider in order for someone to be valuable as an accessibility consultant. It heavily depends on the direction a person is going with this certification. Consultant work for web accessibility is very important work, and it requires someone who is serious and committed to that subject matter. Certification is just one way to show that commitment.

So, what about the rest of us who just want to be better web designers and developers? Is there value in learning all these things with or without the certification? Yes! Becoming better at those three things (creation, identification, remediation) will make you better at your craft. It already has made me better at mine.

What’s next?

Perhaps I did (or didn’t) pass the exam. When the results come back, I will be excited if I did pass, and disappointed if I did not. But all is not lost. I accomplished what I set out to do, which was to become more knowledgeable about the why and the how of web accessibility.

On that note, I want to reiterate that it doesn’t end here for me. There is still so much I haven’t explored, tests that I haven’t run myself, and fixes on personal and business sites that I haven’t corrected yet. And if that weren’t enough, I plan on sitting for the Certified Professional in Accessibility Core Competencies (CPACC) certification exam this Fall so that I can earn credential as a Certified Professional in Web Accessibility (CPWA).

In the meantime, I have a lot of work to do. Find me on Twitter, LinkedIn, or Github if you are interested in or want to talk web accessibility.

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 99: Semantic Elements and Their Quirks

Today I worked on finishing a Deque course about semantic code. All my time got wrapped up in the fascinating aspects of which HTML is read aloud and easily navigable, and which elements are ignored by screen readers.

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • tables
    • lists
    • iframes
    • elements announced & unannounced
    • parsing & validity
  • Navigation keyboard shortcuts for screen readers;

What I learned from it

I’ve been mixing up the purpose to the caption element and the summary attribute for tables. Caption is the accessible name of the table, so it shows up in a list of tables provided by a screen reader. The summary attribute was deprecated in HTML5. Caption should be short, even when including a brief summary. Summary replacements include:

  • putting the table in a figure element, and using figcaption with table aria-labelledby to associate the table with the summary
  • adding an id to a separate paragraph and adding aria-describedby to the table element to point to that p id.

When using iframes, include a title attribute, and ensure the embedded page/content has a title element. Screen readers like JAWS vary in behavior as to which one they read. Also, as a note to myself, I need to start defining the type of content within tthe iframe title attribute, like starting the title with “Video”, so it’s clear what they are accessing.

HTML elements that we can’t rely on screen readers to read aloud, therefore, should provide additional cues for important information:

  • strong
  • em
  • q
  • code
  • pre
  • del
  • ins
  • mark

These have given me a lot to think about and stresses the importance of testing my sites on a few different screen readers and platforms.

Wrapping a code element with a pre element is appropriate, and helps the visual presentation of code blocks.

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 94: Designing an Accessible User Experience, Part 2

“Learning directly from users with disabilities can be one of the most valuable things you can do as a part of the design process.”

Today’s dedicated accessibility time was a continuation of Part 1 on the topic of designing an accessible user experience.

Things I accomplished

  • Continued Deque’s “Designing an Accessible User Experience” course. 67% complete.

What I reviewed today

  • A barrier is exclusion. Exclusion is the failure to meet an accessible design challenge;
  • Plan for accessibility from the beginning and throughout the project;
  • Common design failures:
    • no semantic markup
    • custom widgets without ARIA
    • custom widgets without keyboard focus management
    • poor color contrast
    • visual-only cues for form validation;
  • Test with real users;
  • Disability is a spectrum;
  • Accessible design is often inclusive;

What I learned from it

Referring to statistical probability in math, if you were to target your design at users who fall in the middle of the normal bell curve, you would meet the needs of only 68% of your users. Admittedly, designing for the edge cases requires more skill and planning than designing only for the normal user, but the return is much greater, too.

Best statements of the day

“Knowledge is power… and opportunity… and responsibility. ”

“People with disabilities are in the minority, but that doesn’t make their characteristics irrelevant to the majority.”

Related resource

Day 93: Designing an Accessible User Experience, Part 1

Now that the party is over (my presentations have been given), I’m back on track to going through WAS certification courses on Deque and reviewing information that’s pertinent to my upcoming exam in April. As of today, I’m officially one month away from taking IAAP’s Web Accessibility Specialist certification exam.

Things I accomplished

What I reviewed today

Websites that don’t follow accessibility guidelines and principles are often inaccessible, but they can still be inaccessible (unusable) if only the guidelines are followed and usability testing is not implemented.

Guidelines are a mix of objective (easily testable) and subjective (harder to test).

What I learned from it

Consideration of cognitive disabilities is most neglected when it comes to content creation and website development. Why? Measuring successful access is hard because it’s subjective.

Universal (Inclusive) Design

In 1997, a set of universal principles [PDF] was developed by architects to encourage inclusion of everyone’s needs in the design of buildings and products. Each principle has its own guidelines. The seven principles are:

  1. Equitable use: useful and marketable to people with diverse abilities;
  2. Flexibility in use: accommodates a wide range of individual preferences and abilities;
  3. Simple and intuitive use: easy to understand, regardless of user’s experience, knowledge, language skills, or current concentration level;
  4. Perceptible information: effectively communicates necessary information to the user, regardless of ambient conditions or the user’s sensory abilities;
  5. Tolerance for error: minimizes hazards and the adverse consequences of accidental or unintended actions;
  6. Low physical effort: can be used efficiently, comfortably, and with minimum fatigue;
  7. Size and space for approach and use: provides appropriate size and space for approach, reach, manipulation, and use, regardless of user’s body size, posture, or mobility;

These sound a lot like Web Content Accessibility Guidelines principles and criteria, don’t they?

After reading these, I’m reminded of why it can be so easy to confuse the terms “inclusive” and “accessibility”. Accessibility usually does benefit everyone, but is specifically focused on including a particular group of people (those with disabilities). However, inclusive design is a loftier goal that takes advantage of the fact that designing universally, or with a wider audience in mind, does benefit everyone. I, personally, need to correct myself to use each term appropriately.

An A-ha Moment

Content creators, designers, and developers (all creative people) must be open to feedback about their creation. If not, their product will always fail to be inclusive or accessible. Even people who have been mastering their craft need feedback. Otherwise, the product is just for them and no one else.

I still need to check myself and not take feedback or perceived criticism as a personal attack. Receiving another person’s perspective is actually a building block. My confidence lies in being adaptable and open to revisions for a better end-product, and mastering my craft of design. The joy of creating ultimately relies on the joy of sharing it with others. Very rarely am I a creating art for me, but rather I am hoping to design something that’s usable, beneficial, and enjoyable for other people.

Best statement of the day

“Setting a goal of making things “good enough” for compliance isn’t always good enough for real people. Push the boundaries to create experiences that people with disabilities actually enjoy, not just experiences they merely tolerate.”

The runner up quote from Deque

“Accessibility problems are the result of biased design decisions.”

From A Web for Everyone

“Instead of pretending that hidden away in a vault somewhere is a perfectly “normal” brain, to which all other brains must be compared … we need to admit that there is no standard brain…”