Policies

Why this matters

Policies are written to be understood and enforced. They should establish expectations and consequences.

Qualities of good policies

Enforceable

Some policies are simple to define and enforce.

A policy might be: “All products must pass an automated Google Lighthouse accessibility score of 95 with 0 manually detectable defects.” When incorporated as a product release gate mechanism and followed by manual testing, this policy is easily enforceable and measurable.

Another possibility: “Product owners must see all product demos using the assistive technology.” This is more challenging to enforce and measure without directly observing or adding reporting processes.

Updatable

Policies become irrelevant without an ability to update. Sometimes updates to Web Content Accessibility Guidelines (WCAG) versions include minor additions and other times it’s a complete restructuring of the success criteria. Your policies need to be able to shift with the legal landscape changes.

Adaptable to circumstances

Policies need to be realistically adaptable to fit the business needs of the organization.

For instance, a non-compliant vendor might provide critical functionality but isn’t able to meet compliance standards. Policies then have to compromise until a new solution can be negotiated.

In other cases, because of technical barriers or staffing, remediating existing code may need to be prioritized or take a back seat to await a redesign.

Policy definitions

Inventory of all applications

If it doesn’t already exist, one of your strategic goals must be an inventory of all applications.

Without a regularly updated inventory of all digital applications, including points of contact for each, the number of products that need to be managed cannot be known.

Inventory contents

Application name
Audience: Internal or customer facing
Platform: Web, iOS, Android, Windows, MacOS
Update cadence: Daily, weekly, quarterly, etc.
If produced by your enterprise
- Product owner
- Product manager
- Development manager
- Testing manager
If produced by a 3rd party
- Relationship manager
- Primary account manager

Core functionality meets WCAG AA or AAA

For the uninitiated, it may seem that A, AA and AAA are scores, but this is not how the levels work.

WCAG are a series of criteria used to describe the success or failure of accessibility in types of features. Not every website contains WCAG AAA features (like live captioned events) but practically all contain WCAG AA features.

It’s lengthy and uses technical language, requiring significant study and experience to apply efficiently. It’s not a checklist, but rather a set of rules by which an application can be analyzed.

How to simplify WCAG

While WCAG is an incredibly useful bottom line legal definition of accessibility policy, communicating these requirements to teams will require conversion to plain language.

Example: WCAG Success criteria 2.1.1

Success criteria 2.1.1 Keyboard (Level A): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.

Plain language example

Using only a keyboard (no mouse) all interactive elements (links, buttons, inputs) are intuitively and visibly functional.

Severity, priority & remediation guidelines

Define severity/priority of varying levels of defects with examples. This allows teams to prioritize work efficiently.

Severity definitions

Severity is an objective scale. It’s important that teams agree on a uniform definition so issues are remediated in a meaningful way.

Blocker
- Impossible to overcome using expected interactions
High
- Difficult to perceive, operate or understand an application’s core functionality on the first try
Medium
- Aggravating, but can be worked through with some persistence
Low
- Can be bypassed with modest effort

Priority definitions

Testers will determine the severity of defects, while the product management team will decide how to prioritize the defects for remediation.

Priority is subjective, and may be based on several factors. A high severity defect on a rarely trafficked page may take a back seat to a medium severity defect on a homepage.

Legal risk and liability objectives also affect priority. A high severity color contrast issue might be remediated after a medium severity screen reader issue because of the higher complaint risk.

Deadlines for remediation

Establish a minimum deadline for remediation from when a defect is recorded.

You can typically operate within 2 week release cycles for medium and low issues, but blocker or high severity issues may call for an immediate hotfix.

Depending on the severity and complexity of the fix, there may be a negotiation between the accessibility team and the product’s managers.

When is an urgent hotfix called for?

Basically, don’t operate with double standards.

When a high priority change occurs outside of scheduled releases, it’s typically called a hotfix. Hasty changes entail disruptive effort and are generally called for sparingly.

If a defect wouldn’t be tolerated for customers not using assistive technology, you shouldn’t de-prioritize it for those who are.

You would call a hotfix for a purchase flow that can’t be completed using a mouse. A similar hotfix should exist for a purchase that can’t be completed with a keyboard.

Training competencies for team members

Use these guides to establish training requirements by role:

Gating and escalation procedures

Employ manual and automated test tools uniformly across development, QA and deployment pipelines. A high degree of quality control gating will follow.

Automated gating

Automated tools only catch a fraction of accessibility defects affecting the customer experience. They are most useful at identifying signals of poor coding practices.

Escalations & exceptions

Inevitably, a team will desire to deploy code below a minimum accessibility requirement and ask for an exception.

High-level leadership and possibly legal counsel should be responsible for approving exceptions with advice from the accessibility team.

Why escalate to leadership and not the accessibility team?

Bringing requests for exceptions to leadership discourages teams from attempting to launch inaccessible features because they will want to avoid negative scrutiny from management.

This also means the accessibility team can continue building relationships and not be seen as the police.

It’s also possible there is a significant business reason for an exception that the accessibility team isn’t fully aware of.

Reasons a feature may need an exception

Content is part of a scheduled (and expensive) advertising campaign
A component is part of a greater sweeping change aligned with partner organization schedules
The feature is required for an unyielding legal mandate

What happens after an exception is made

If an exception must be made, record the issues and follow remediation policies post deployment.

Procurement procedures for vendors

Procedures should require vendors to provide a Voluntary Product Accessibility Template (VPAT) with a reliable validation of that VPAT through manual assessment.

All vendors are briefed on requirements

It’s important that vendors understand it’s their responsibility to deliver working accessible products to your organization.

Beyond including contractual accessibility requirements that align with your own policies, vendors need to be specifically informed accessibility is a requirement and that a VPAT a validation plan is required for consideration.

Voluntary Product Accessibility Template (VPAT) provided

The VPAT is a voluntary document to be completed by the vendor that details the accessibility compliance or lack thereof.

A VPAT is not proof that a product is accessible, in fact it can document that a product is not accessible.
A VPAT by itself is not the same as an full accessibility assessment

VPAT validation plan

Without a trustworthy evaluation of the product, the VPAT could misrepresent the vendor’s level of accessibility compliance. Validation of a VPAT can be conducted by a respectable third party.

If the vendor can reliably document their own procedures and level of expertise, it may acceptable for a vendor to validate their own VPAT.

Policy communication

Don’t underestimate the effort involved communicating policies clearly and effectively.

Plain language explanation of policies

While WCAG is helpful in setting a functional specification for success criteria, it’s not enough to declare WCAG as your policy requirement and expect results. Policies must be consumable by product teams to be heeded.

Start by using a set of simplified rules for accessibility compliance. You can reduce the feeling of being overwhelmed by new requirements for teams.

Policies published as web pages

Do not rely on email and PDFs to distribute policies. Policies need to be published in a web page format.

This allows anyone in the organization easy access, and it gives the accessibility team the ability to make quick updates.

All teams are briefed on policies

It’s not enough to publish and email new policies. They have to be proactively communicated. It may be necessary to invest in an enterprise-wide briefing on policies and incorporate it into new employee onboarding training.

Policies visibly endorsed by leadership

Gain leadership’s backing early on for your strategic goals and these policies.

Without visible endorsement, some teams will try to ignore, go around or misrepresent their compliance, especially if they believe there will be no consequences.