Policies

Why this matters

In crafting and socializing understandable policies, a market is created for the expertise and services the accessibility team will deliver to the enterprise.

Qualities of good policies

Policies are meant to be interactive, otherwise they become yet another legal compliance checkbox to receive minimized attention.

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 new versions of the Web Content Accessibility Guidelines (WCAG) include minor additions; other times it’s a complete restructuring of the success criteria. Your policies need to be able to shift with 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 essentials

These policies ensure the information, language and rules surrounding accessibility are uniform.

If there are multiple sources of incomplete information, policies become open to interpretation.

Applications are registered in a single inventory

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 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 subjective scale. It’s important 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 subjective severity of defects, while the product management team will decide how to objectively prioritize the defects for remediation.

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

For example, in a typical agile workflow operating within 2 week release cycles, most medium and low severity issues can be remediated in 1-2 sprint cycles. A blocking or high severit issue may call for an immediate hotfix deployed out of cycle.

Be adaptable

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.

For example: andy product manager would demand a hotfix when the purchase flow can’t be completed using a mouse; thus 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 the accessibility team isn’t fully aware of.

Reasons a feature may need an exception

Content is part of a tightly 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 through manual assessment (not just automated tools).

All vendors are briefed on requirements

Vendors must understand it’s their responsibility to deliver working accessible products to your organization.

Beyond including contractual accessibility requirements aligned with your own policies, vendors need to be specifically informed accessibility is a requirement and 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 detailing the accessibility compliance (or lack thereof).

A VPAT is not proof a product is accessible, in fact it can document 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 on a regular basis.

Invest in an enterprise-wide briefing or training on policies and incorporate it into new employee onboarding training.

Policies visibly endorsed by leadership

Gaining leadership’s backing includes endsorsement for your strategic goals and the policies steering the enterprise toward them.

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