Organizational Governance & Management

Organizations should develop a way to manage, govern, and enforce accessibility standards, best practices, and law. Remediation and retrofitting is not the answer. Processes organizations should establish and manage:

Integration Management

Accessibility is more than a technical challenge; it’s a process management challenge. Change starts with the establishment of a team of people, who express interest in accessibility, and represent several departments within the organization. Tasks include:

  • identifying the goals and objectives of implementing accessibility;
  • selecting internal standards, best practices, resources and tools needed to incorporate accessibility; and
  • specifying accessibility guidelines and policies for the entire organization.

Web Development Process

Plan. Create. Test. These are the 3 tasks to cycle through during the process of developing a new site/design, new feature, or remediation of a site. Accessibility experts and people with disabilities need to be part of these various stages to ensure quality and usability of the end product.

Plan and design phase includes:

  • research,
  • requirements, and
  • design of information architecture (IA) and user experience (UX).

Create content & components phase includes:

  • creating front-end markup & programming
  • creating text content
  • testing multimedia

Test content and components phase includes:

  • testing markup & programming
  • testing text content
  • testing multimedia

Scope Management

Set clear expectations and milestones for when your project is “done.” Accessibility review is always on-going, but there should be definitive policies about what is acceptable to be pushed to production and what is not. The general categories of accessibility scope are:

  • innovation (new technologies or techniques)
  • new design (new project)
  • retrofitting (fixing existing project by inventory, assess, and prioritize)
  • maintenance (testing updates of project with automation)

Time Management

Best-case scenario says that only 1-5% of development time will be for accessibility efforts. Worst-case scenario paints a more grim picture that accessibility efforts may cost a team 2-3x the usual development time. Sadly, the last scenario happens all-too-often because teams don’t know much about web accessibility, don’t have a process in place, and resort to trial-and-error along the way. Accessibility can cost the team even more time if there are no experts on any level of the organization. To ensure that time is reduced on the accessibility of a project, the following are a must:

  • accessibility expert on staff
  • all team members are educated about accessibility
  • accessibility is embedded in the process
  • accessible patterns and methods are available
  • a flexible development environment
  • automated testing tools

Cost Management

Most of the cost of accessibility will be due to time management decisions. However, there are a few additional items to keep in mind:

  • third-party consultation
  • enterprise-level accessibility software for testing (audits, AT)

Quality Management

During the planning phase, there should be:

  • tests written for accessibility requirements,
  • user stories generated,
  • acceptance criteria to determine achievement of design requirements,
  • bug reporting, and
  • manual testing performed by actual people with disabilities.

Human Resource Management

Not only should teams recruit people with disabilities for testing, but the organization should take it a step further and hire people with disabilities to be on the team. In addition to hiring people with disabilities, organizations should hire accessibility experts that have been trained and certified to evaluate with accessibility in mind. And, to make an even stronger accessibility-minded organization, it’s pivotal to train all team members about accessibility.

Communication Management

Speaking of training all team members, from product manager, to designer, to developer, HR management segues into communication management. Informing the entire team that accessibility is business as usual, and all members are required to have a degree of accessibility knowledge can increase the strength and maturity of the organization’s accessibility policies. Having an accessibility lead on staff, who has power to support continuing education for all staff, adds to that strength.

Risk Management

Risk management is the examination of the organization’s:

  • legal liability,
  • public relations (PR) status, and
  • accountability.

Legal liability is based off of how bad the accessibility issues (barriers and blocks) are for people with disabilities (see Day 84: Strategies and Techniques for Fixing A11y Issues). Each organization may have a higher risk of lawsuit if key actions for their site are not achievable.

Negative PR is worse than no PR. No organization one’s to be cast as a discriminating (implicit or explicit) business.

As for accountability, this is an internal process. Managers and supervisors need to hold staff accountable to accessibility efforts throughout each process.

Procurement Management

As I mentioned in The Many Laws of Accessibility, Part 2: Laws & Regulations, procurement is the process of purchasing goods and services from external sources. Each organization should “try before they buy”. In other words, when outsourcing for services and products, organizations should:

  • only buy accessible products, whether for internal or public use,
  • verify the accessibility claims from the vendor, including asking for and reviewing their VPAT (voluntary product accessibility templates),
  • write accessible outcomes into the contract,
  • verify contractor’s accessibility expertise, and
  • leverage procurement policies to motivate vendors to do better.

Stakeholder Management

Stakeholder management is as simple as considering all the people involved to make an accessible product happen. In best of times, stakeholders may be, but are not be limited to:

  • designers,
  • developers,
  • testers,
  • clients or users, including people with disabilities.

If your organization didn’t follow through with other management items mentioned earlier, then you may be adding lawyers, a person(s) who filed a complaint, and a judge. So, make a list, check it twice, and keep all these people involved throughout the plan, create, and test process.

The End

That’s all, folks! This is the end of my CPACC studying. By the time this has published, I’ll have completed the exam, for better or worse. Follow-up reflections soon to come.

Now it’s time for your journey. Get learning and start today with making the web more accessible!

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