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…”

Day 92: A Day of Two Presentations

Whew, what an exhausting day! After presenting two different accessibility sessions at the Alaska Library Association conference today, I’m beat. The amazing part was the active engagement from participants, and the ability to still learn something from the co-presentation I was a part of.

Things I accomplished

  • Co-presented about accessible workstations in libraries, with my part focused on people with disabilities who may come into their library.
  • Presented about creating Word docs and PowerPoint slides with accessibility in mind.
  • Completed Deque’s MS Word Accessibility course.

What I reviewed today

  • U.S. law for people with disabilities
  • accessible electronic content (Word and PowerPoint)

What I learned

The Americans with Disabilities Act (ADA) was written in a such a way to benefit everyone. Whether born with a disability or acquired later in life, it’s there to serve us all.

I knew about the Word’s export to HTML feature, though I don’t like it. What I didn’t know is that there is another save for web option: Web Page, Filtered. This removes all that excess (ugly) code that forces formatting as inline styles. Styles are separated. I haven’t given it a try yet, but will give it a try later on this week.

Day 91: Accessible Word Docs

Yesterday I learned that documents like Word and PowerPoint are considered non-web documents under Section 508. However, WCAG (minus 4 success criteria) should still be applied to these files to ensure accessibility.

I’ve done several trainings, workshops, and one-on-one training sessions to educate others about digital document accessibility, but I always feel like I learn something new when I take other people’s courses and workshops. Plus, this is the perfect preparation for me to give another workshop about accessible digital documents.

Things I accomplished

  • Practiced my Accessible Digital Documents talk for tomorrow.
  • Worked through 60% of Deque’s MS Word Accessibility class.

What I reviewed today

Adding structure and semantics to Word docs to increases its accessibility and usability. Structures and semantic elements to focus on when creating a Word document:

  • headings
  • table of contents
  • language
  • headers & footers
  • floating objects
  • footnotes and endnotes
  • abbreviations and acronyms
  • columns
  • links
  • superscripts & subscripts
  • page numbers

Styles should not be used to convey important meaning. This includes using bold, italics, strike-through, and highlighting.

What I learned from it

Turns out my knowledge of Word doc accessibility was challenged a bit. I’d heard that Word documents offered specific accessibility perks compared to other formats like PDF, when used appropriately. However, Deque proved that wrong. Word docs and PDFs each present accessibility challenges to VoiceOver users. Their point being that creating online content within HTML is the most accessible, which I did know already.

I tested a .docx file on Mac by opening it up in Pages. Semantics still remained. However, testing that same file on my iPhone with Previewer, those same semantics didn’t carry over.

Something else I learned that had to overwrite old thinking was that all text formatting is not read (by default) by screen readers. I knew styling was ignored, but I didn’t know screen readers went as far as ignoring bold, italics, strike-through, and highlighting, unless otherwise changed in the user settings. The best way to draw attention to key points and important items is to literally include those words in the text. As a perk, that method can draw attention for sighted users with reading or cognitive disabilities.

On the topic of text styling, I learned that drop cap letters are read weird by screen readers. The drop cap letter is read separately from the rest of the letters of the word.

Special characters are not all understood by screen readers either. Including explanation alongside those characters increase their accessibility.

Use Text Effects, instead of Word Art, which is an object that is out of the flow of the document. This increases accessibility of pretty text for screen readers. Use caution with Text Effects, though, because it could decrease accessibility for people with low vision.

Day 90: Section 508 and the ADA

I’ve had an accessibility-heavy week! However, it’s not without it’s rewards. I’ve found that sometimes on these journeys, ideas start to synchronize, articles relevant to what I’m questioning start to emerge in my Twitter feed, and people approach me about ideas or questions they have that spur me on further. In line with a talk I’m giving this weekend and the classes I’m taking through Deque, the U.S. laws that protect the civil rights of people with disabilities kept coming into question in my mind. It’s only appropriate that I spent a little bit of time with those fundamentals today.

Things I accomplished

  • Updated my presentation slides about people with disabilities.
  • Updated my presentation slides about accessible digital documents.
  • Completed Deque’s class “Section 508: Fundamentals of the Law and Technical Standards”.

What I reviewed today

The Americans with Disabilities Act of 1990

Covers:

  • Title I (workplace)
  • Title II (state and local government services)
  • Title III (public accommodation and commercial facilities)
  • Title IV (telecommunications for speech and hearing impaired)
  • Title V (federal enforcement of ADA)

[Federal] Rehabilitation Act of 1973 (amended in 1998)

  • Section 501 (federal employment)
  • Section 502 (enables role of Access Board, which defines ICT and accessibility standards)
  • Section 504 (federally-funded programs and services, including schools)
  • Section 508 (refreshed in 2018; federally-funded information and communication technology), usually enforced with 501 or 504.

What I learned from it

Federal laws were instated to protect people with disabilities, as well as present an example to state and local governments, plus private entities. Laws focus on physical and electronic access.

Physical:

  • Architectural Barriers Act (ABA)
  • Americans with Disabilities Act (ADA)
  • Section 504 of the Rehabilitation Act

Electronic:

  • Section 508 of the Federal Rehabilitation Act
  • Americans with Disabilities Act (ADA): for state and local governments
  • Section 255 of the Telecommunications Act

The ADA is essential a blanket civil rights law that protects the equal treatment of people with disabilities. Many lawsuits are championed with the ADA.

The Section 508 refresh specifically references WCAG 2.0, Level AA:

“E205.4 under Electronic Content indicates the accessibility standards for electronic content shall conform to WCAG 2.0 Level A and AA Success Criteria and Conformance Requirements”

However, non-web documents and non-web software are not required to meet four criteria:

  • 2.4.1 Bypass Blocks
  • 2.4.5 Multiple Ways
  • 3.2.3 Consistent Navigation
  • 3.2.4 Consistent Identification

There are some ICT exceptions in Section 508. These exceptions are:

  • Legacy ICT (“Safe Harbor”; created before January 17, 2018 and compliant with previous 508 standards)
  • National Security Systems (weapons or intelligence)
  • Incidental Federal contracts
  • ICT functions located in maintenance of monitoring systems
  • Undue burden or fundamental alteration (significant difficulty or expense, or alters the fundamental nature of the ICT)
  • Best Meets (a balance between Section 508 and agency needs, if compliant ICT is not available commercially)

The only exceptions to agency official communication (as opposed to public facing) being compliant with Section 508 are any records maintained by the National Archives and Records Administration (NARA) obsolete to Federal recordkeeping statutes.

Whew! And there’s still so much to learn…

Day 89: Writing a Real Accessibility Evaluation

Today I had the joy of practicing what I’ve been learning over the last 88 days. I’ve been itching to work through a formal evaluation, and this real opportunity came up.

Things I accomplished

  • Presented an accessibility issue to an accessibility working group that I chair.
  • Wrote an official evaluation to a separate working group to present aforementioned findings in a formal way.

What I reviewed today

First, I gathered the details that I’d written down. Next, I walked through the WCAG-EM Report Tool to reaffirm my findings, as well as add to them. Lastly, I composed a formal evaluation of the features that were not in conformance with WCAG 2.1, Level AA.

The base outline of my evaluation:

  1. Overview
  2. WCAG-EM evaluation
    1. Scope
    2. Failures
  3. QA testing
    1. Automated testing
    2. Manual testing
    3. Personas
  4. Remediation recommendations

What I learned from it

The process of evaluation can take a quite a bit of time, especially for someone who is new. I had to re-read many WCAG success criteria over again, limit my scope, and deeply think about what techniques were sufficient, advisory, or failures. Additionally, I encountered some bad practice and some not-so-optimal coding solutions, but refrained from delving into those since they are were not part of the aim of conformance. It was a true learning experience, and one I hope to refine over the next few years!

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 87: Guidelines, Laws, and Myths

My intention today was to complete the first Deque course within the WAS certification prep program. I did do that, but not without being led to more resources that I need to read through. I’ve done a little research into US laws, but I need to read them again, plus read other laws mentioned in what I reviewed today. Looks like tomorrow’s study session is laid out for me.

Thing I accomplished

Completed guidelines, laws, and myths sections of Deque’s Accessibility Fundamentals.

What I reviewed today

Guidelines

Principles, guidelines, and authoring practices help create an accessible interaction between user and website or application. These guidelines and practices ensure that a variety of disabilities are taken into consideration.

I covered these more in detail on my own, which I’ve journalled on this site, but Deque does a decent job of getting the learner started with the basic principles and guidelines, and points them to official specifications. I’ll admit, I need to go back and spend some serious review time to go over all these.

Laws

Web accessibility laws usually fit into one of the following categories:

  • civil rights: discrimination against disabilities (Americans with Disabilities Act)
  • procurement: purchasing accessible IT products (Section 508 of the Rehabilitation Act)
  • industry-specific: regulations for private industries (21st Century Communications and Video Accessibility Act, Air Carrier Access Act)

United States

Canada

Europe

Other Regions

The Web Accessibility Initiative (WAI) has a comprehensive list of international accessibility policies. Additionally, PowerMapper has a list of government accessibility standards.

Myths and Misconceptions about Accessibility

  1. It benefits only a small minority. Truth: It actually benefits everyone.
  2. It’s a short-term project. Truth: It’s on-going.
  3. It should be the last step. Truth: It needs to start at the beginning of the project and last throughout the project’s life cycle.
  4. It’s hard & expensive. Truth: Remediation is harder and more expensive than considering it throughout the life cycle.
  5. It’s ugly. Truth: Most accessibility features are not visible to everyone.

Best takeaway

“Inaccessible web sites are not just inconvenient for people with disabilities, they are blocking.”

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 84: Strategies and Techniques for Fixing A11y Issues

Eighty-four (84) days in, and I made it to the end of the WAS Body of Knowledge (BOK)! I’m ready to go back through all my blog posts (journaling) to review things that I’m so nervous about forgetting by April. This will include pouring over the W3C’s Web A11y Evaluation Background Reading materials. I’ll also spend the last few weeks of these 100 days to work through the Deque courses that apply to this certification, and tie together ideas that will help me be a better Web Accessibility Specialist (WAS) in practice.

Today’s study session felt less productive, due to the topic implying review and application of all the things learned to be a WAS. However, the day did not go by without some positive steps toward taking the exam.

Things I accomplished

  • My request to take the WAS certification exam was accepted today, so I registered for the exam.
  • Read over the last section of the BOK: Recommend strategies and/or techniques for fixing accessibility issues.
  • Continued further through the Deque Accessibility Basics course.

What I learned today

A specialist or expert in web accessibility should have a solid understanding of:

  • how to evaluate web content using WCAG 2.0,
  • accessible web design,
  • web technologies,
  • assistive technologies,
  • how people with different disabilities use the Web,
  • accessibility barriers that people with disabilities experience,
  • assistive technologies and adaptive strategies that people with disabilities use, and
  • evaluation techniques, tools, and methods to identify barriers for people with disabilities.

Additionally, I think this person needs to bolster their project management and communication skills. Not only will they know what they’re talking about, but help educate and encourage the people they are helping with evaluation and remediation. A teacher and project manager, of sorts. Accessibility Pro Certified: To Be or Not To Be is a wonderful article that takes into consideration the idea of certification and what makes an accessibility pro or expert.

In order to recommend remediation strategies, a specialist has to understand:

  • how to create accessible content (the first major section of the BOK)
  • identify accessibility issues (the second major section of the BOK)
  • wisely choose an appropriate remediation technique that fits the goals and limitations an organization is working within (the third major section of the BOK)

This last study topic section in the BOK made me reflect back on all the considerations that go into prioritizing remediation, which often comes down to a balance of user and business impact. It circles back nicely to the start of the BOK, where I need to fully understand what accessible content is and how inaccessible content impacts users with disabilities.

 

Day 83: Prioritizing Remediation of A11y Issues

During today’s study session, I walked away with a lot of new-to-me information and useful steps to apply to my current work.

Things I accomplished

What I learned today

When starting an accessibility remediation project, start with a site’s core functionalities. Determine the issue’s origin (markup, style, functionality), then prioritize accessibility issues by severity of:

  • impact on users: does the problem have a user workaround or are they completely inhibited (blocked) from using a core functionality?
  • legal risk: related to user impact; is it a legal risk (based on functionality block and type of organization) or just a usability issue? take note of perceivability and repeat offenders
  • cost benefit: is the ROI greater than the time invested to remediate or lawsuit that may occur?
    e.g. ROI = ((Risk Amount – Investment) / Investment) * 100
  • level of effort to remediate (impact on business): how many changes (and where) have to be made?

WCAG conformance levels and success criteria are not the way to determine priority of remediation.

As mentioned in my notes about manual versus automated testing tools, it’s always best to target low-hanging fruit to begin quickly resolving issues.

When receiving an audit to proceed to remediation, people want to know:

  • where the problems are
  • what the problems are
  • how to fix them
  • not the specific technical guidelines and success criteria

Remediation is a hard lesson to learn in realizing that if things are made accessible from the start, less time and money is wasted.

Time is money. Just because you save time taking down inaccessible materials, time is added (technical debt shifted) to help desk lines or other resources.

I really liked Michigan State University’s accessibility severity scale:

  1. Level 4, Blocker: Prevents access to core processes or many secondary processes; causes harm or significant discomfort.
  2. Level 3, Critical: Prevents access to some secondary processes; makes it difficult to access core processes or many secondary processes.
  3. Level 2, Major: Makes it inconvenient to access core processes or many secondary processes.
  4. Level 1, Minor: Makes it inconvenient to access isolated processes.
  5. Level 0, Lesser: Usability observation.

Remediation procedure levels by Karl Groves:

  • simple: prioritization: time versus impact (user-centric)
  • advanced prioritization: scoring business and user impact (broken down by user type)
    (Impact + Repair Speed + Location + Secondary Benefits) * Volume = Priority

Best quote from today’s Deque course

Accessibility does not happen by accident. It has to be purposefully planned, built, and tested for accessibility.