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 36: Questions to Ask throughout the Product Life Cycle

Today wrapped up my research for the week about integrating accessibility into a product’s life cycle. I ended with reviewing what a product’s life cycle looks like, and how everyone can play a role during each phase to ensure accessibility is considered throughout development, rather than an afterthought.

Things I accomplished

What I learned today

Stages of a product’s lifecycle with accessibility questions to ask at each stage:

  • concept: does it solve a problem for people with disabilities? what are the different user needs?
  • requirements: what accessibility standards/laws does it need to follow?
  • design: do the mockups create any barriers?
  • prototyping: does the prototype create any perceivable, operable, or understandable errors?
  • development: is the code following standards? are appropriate patterns being used?
  • quality assurance (QA): are automated and manual accessibility checks being run?
  • user acceptance testing (UAT): does this product work for real users with disabilities?
  • regression testing: when updates are made, are checks still passing?

Day 35: A11y Verification Testing as Part of User Testing

Today’s mission was to reflect on user (usability) testing, and search for accessibility verification testing (AVT). AVT was new to me, and I had a harder time finding that exact word combination when searching the web. So, I ended up reading about accessibility user testing and manual testing a developer can perform on her own to emulate user testing.

Things I accomplished

What I learned today

  • Accessibility testing is subset of usability testing.
  • User testing for accessibility requires recruiting real users with disabilities. The rest is much like general user testing:
    • observing them in an environment familiar to them,
    • assigning tasks to accomplish,
    • observing unspoken actions,
    • scrutinizing results, and
    • conclude what changes need to happen.

Cool resource

Designing for Guidance (Microsoft) [PDF] offers tips about the varied learning styles that people have. With the approach of inclusive design in mind, this tiny booklet will make you think more critically when you develop a product or learning course for your large audience.

Day 33: A11y, UX, or Both?

Things I accomplished

What I learned today

Comparing accessibility and user experience, both have benefits for all, yet differ mostly by audience:

  • accessibility
    • audience: people with disabilities
    • intent: the targeted audience can perceive, understand, navigate, and interact with websites and tools (an equivalent user experience)
  • user experience
    • audience: anyone
    • intent: a product should be effective, efficient, and satisfying

Accessibility includes a more technical aspect (considerate of assistive technologies, for instance); UX is more principled in its approach.

Usable accessibility = a11y + UX.

Accessibility is just one aspect of the “universal web”.

Looking at accessibility a little closer, what makes a person disabled? We may think of someone with a disability as having a certified report by a doctor or proving an obvious physical or mental difference from our own. Yet disabilities are actually better defined as a conflict of a person’s ability with their environment. It puts us all on a spectrum, doesn’t it?

An accurate statement

“For people without disabilities, technology makes things convenient. For people with disabilities, it makes things possible.” – Judith Heumann, U.S. Department of Education’s Assistant Secretary of the Office of Special Education and Rehabilitative Services

Factoid resource

  • Section 255 of the Telecommunications Act of 1996: Fueling the Creation of New Electronic Curbcuts
    A timeline of IT innovations built for someone with disabilities, but made its way into mainstream tech use. To my surprise: the typewriter!

Day 32: Benefits of Designing for A11y

Things I accomplished

What I learned today

There are several benefits to starting out a design process with accessibility in mind, rather than catching it after production and resorting to remediation. Some of these benefits include:

  • a solid customer base due to an off-the-shelf accessible product,
  • saved money by building it right rather than redesigning over and over again,
  • minimized legal risk,
  • innovation and the challenge to solve real-world problems,
  • improved productivity,
  • improved diversity, and
  • improved corporate image and brand when accessible technologies and strategies are incorporated within their organization.

Day 31: A11y throughout a Product’s Lifecycle, Waterfall vs. Agile

Moving onto the next WAS Body of Knowledge study topic: integrating accessibility into the quality assurance process. Approximate study time: 1 hour.

Things I accomplished

What I learned today

Considering accessibility shouldn’t just happen at the mockup or code level. It can happen throughout the product’s entire life:

  • concept,
  • requirements,
  • design,
  • prototyping,
  • development,
  • quality assurance,
  • user testing, and
  • regression testing.

Additionally, I read about the agile and waterfall processes and when to apply accessibility when working through the cycle:

  • waterfall approach: present throughout each step and is well documented
  • agile approach: discussed at scrum meeting, established as a requirement, built into design and architecture, use standardized testing with TDD and automation

Love this statement by Karl Groves which nails it when it comes to encouraging the development of an accessible product rather than blockading it:

“Become a member of the team, not a gatekeeper, and you will be seen as a resource instead of a hurdle.”