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

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 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 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.

Day 82: Testing with Users with Disabilities

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

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

Things I accomplished

Read:

What I learned today

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

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

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

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

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

Further reading

 

Day 81: Manual vs. Automated A11y Testing Tools

Today I went into my study time with the intent to list out pros and cons of automated versus manual accessibility testing. Instead I walked away with a comparison of what each had to offer, and understanding that both are valuable when used cooperatively during website and web app development.

Things I accomplished

Submitted my request to take the Web Accessibility Specialist certification exam in early April via private proctor.

Read:

Created a comparison table to jot down ideas about manual and automated testing (see under What I learned today).

What I learned today

Manual Testing Automated Testing
Slower process Faster process
Mostly accurate Sometimes accurate
Easier to miss a link Guaranteed check of all links
Identifies proper state of elements Automated user input can miss state
Page by Page Site-wide
Assurance of conformance Misleading in assurance of conformance
Guidance for alternative solutions Yes/No (boolean) checks and solutions
Human and software Software
Context Patterns
Finds actual problems Lists potential problems
Appropriate HTML semantics HTML validation
Accurate alt text Existence of alt attribute
Heading hierarchy Headings exist
Follows intention of usability Follows WCAG success criteria
Test is/isn’t readable Programmatic color contrast
Exploratory Automated
Part of the testing process Part of the testing process
Appropriate use of ARIA Presence and validity of ARIA
In real life Hypothetical
Identifies granular challenges of usability Quickly identifies low-hanging fruit and repeated offenders

In conclusion

Deciding on testing methods and tools shouldn’t be an either-or mandate. Each has their strengths and weaknesses. Using both methods should be a part of every testing process. Why not strengthen your product’s usability by incorporating tools from each methodology into your process?

Day 80: Manual A11y Testing Tools

Yesterday I browsed through automated accessibility testing tools. Today, per their mention in the WAS Body of Knowledge, I discovered some manual accessibility testing tools that offer more insight into problems that can’t be caught in automated reports. These tools go beyond the easy checks, like color contrast, headings, and keyboard access, that I’m used to checking for.

Tomorrow I hope to dig in a bit deeper to compare the difference between automated and manual testing, along with the drawbacks of each.

Things I accomplished

What I learned today

Manual testing tools, much like automated testing tools, offer reports and automated tests for all audiences within the development process to get a start on addressing accessibility issues. The advantage that manual tooling provides is that it offers additional guidance and education to fix problems that cannot be systematically evaluated through automated checkpoints. However, no tooling replaces human judgement and end-user testing.

Manual testing tools can include:

  • guided manual testing and reports, based on heuristics (WorldSpace Assure)
  • browser inspector tools and add-ons (accessibility audit in Chrome DevTools)
  • accessibility API viewers (Accessibility Viewer views the a11y tree)
  • simulators (No Coffee visual disabilities simulation)
  • single (heading levels) and multi-purpose (many checkpoints) accessibility tools

Another observation about manual testing tools, they may take more time to work through results, but there are many more of these tools that are free to use compared to automated full website testing.

Though I found that many manual testing tools seem to fall with between the development and testing, there are some system-wide tools that help earlier on in the life cycle. Color Oracle is one such application that can assist designers during the earlier design process before any code is written. It takes colorblindness into consideration at the beginning of the site’s life cycle.

An Aside

Ran across an accessibility basics article by Microsoft, and loved this catchphrase:

“Accessibility is a built-in, not a bolt on.”

Day 78: Learning about Orca

Orca is an open source screen reader for Linux. This is my first time to read about it. Hopefully, I’ll have a chance to actually experiment using it. However, I’ll need to set up a Linux distribution that works with it first.

Things I accomplished

  • Attempted to install Orca on my netbook (Lubuntu), and then on my Raspberry Pi (Raspbian). Both failed attempts (today, anyway).
  • Read through a lot of Orca documentation.
  • Added keystrokes to my screen reader cheatsheet, and copied the spreadsheet over to my WAS cheatsheets on Google Sheets.

What I learned today

  • Orca can provide speech or braille output.
  • Orca is provided as a default screen reader for several Linux distributions, including Solaris, Fedora, and Ubuntu.
  • Orca provides a really cool feature called Where Am I that allows additional commands to inform the user about page title, link information (location, size), table details, and widget role and name.
  • Many of the navigation keystrokes are similar to other desktop screen reader commands.
  • Orca also has commands specific to dealing with Live Regions on webpages.
  • When the “Super” key is referenced, it’s talking about the Windows logo key.
  • Orca provides Gecko-specific navigation preferences. I wonder if it works best with Firefox?

Not only did I learn about Orca, but I also got sucked down the Linux rabbit hole in order to better grasp that OS, its distributions and desktop environments, and additional “universal access” for people with disabilities. However, that topic could take another week to work through.

Day 77: Experimenting with Window-Eyes

Window-Eyes is a screen reader that appears to have fallen out of the mainstream use. According to WebAIM’s latest Screen Reader Survey, 1.5% of their respondents reported that they use Window-Eyes. I experimented with it because it was listed as an example of an assistive technology to experiment and test out.

Things I accomplished

What I learned today

  • Window-Eyes works best with Internet Explorer.
  • Window-Eyes was folded into the AI Squared family, and there are instructions on how to migrate from Window-Eyes to JAWS (mp3).
  • Window-Eyes is free to download if you have a registered copy of Microsoft Office.
  • Most keystrokes are similar to other Windows screen readers, but uses Control or Insert keys as modifier keys.

Day 74: Striving for WCAG Level AAA, Part 3

Today I spent time with the Understandable Level AAA criteria. Some of the Readable Guideline’s success criteria (SC) seem like a nice effort to make for everyone who comes to your site. However, I can see how that can take a lot more communication between content creator and developer to provide the necessary additional content or appropriate code to implement sufficient techniques correctly.

Things I accomplished

  • Read Understandable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 7 Level AAA criteria under Understandable, none of which are new to 2.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)

There are 0 Level AAA criteria under Robust.

Examples of Understandable Level AAA failures

SC 3.1.3 Unusual words Fail: Specialized words are used in the content, but no definitions are provided. Providing definitions or a glossary would greatly benefit people with cognitive, language, and learning disabilities.

SC 3.1.4 Abbreviations Fail: Abbreviations are present, but no expanded form is available on the page, in assumption that the user already knows what it means. This can create confusion for people with cognitive issues or those using a screen magnifier (which challenges contextual cues).

SC 3.1.5 Reading level Fail: No summary or additional visuals are provided for reading level below 8th grade. This may inhibit people with reading disabilities or English as a second language from understanding your content.

SC 3.1.6 Pronunciation Fail: No audio or text pronunciation is provided for difficult words. This hinders people who use screen readers and people with reading disabilities from fully understanding the content provided.

SC 3.2.5 Change on request Fail: A new window opens when the user clicks on a link without the user expecting the change of focus to a new window. Related to SC 3.2.1 and SC 3.2.2. This greatly affects people who use screen readers.

SC 3.3.5 Help Fail: A form supplies no detailed instructions about data format or additional information necessary to submit the form. Leaving out required information and helpful tips can hinder people with visual, cognitive, or motor disabilities form submitting the form correctly.

SC 3.3.6 Error prevention (all) Fail: A form that is not a legal, financial, or data transaction fails to provide a reversible, review, or confirmation step when error is possible. Related to SC 3.3.4. This may affect people with reading or motor disabilities.