Why this matters
Policies are written to be understood and enforced. They should establish expectations and consequences.
Qualities of good policies
Some policies are simple to define and enforce.
A policy might be: “All products must pass an automated Google Lighthouse accessibility score of 95.” When incorporated as a product release gate mechanism, it’s 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.
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.
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.
- 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 is an objective scale. It’s important that teams agree on a uniform definition so issues are remediated in a meaningful way.
- Impossible to overcome using expected interactions
- Difficult to perceive, operate or understand an application’s core functionality on the first try
- Aggravating, but can be worked through with some persistence
- Can be bypassed with modest effort
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 time for remediation when a defect is found. 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 legal counsel and the product managers.
When is an urgent hotfix called for?
When an urgent deployment occurs outside of scheduled releases, it’s called a hotfix. Hasty changes can have unintended consequences and should be called for sparingly.
Basically, don’t operate with double standards.
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:
- Design systems
- Component library
- Infrastructure and architecture
- Product owners/managers
- CMS authors
- QA testers
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 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 likely want to avoid negative scrutiny from management.
This also allows 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, and in the bigger picture, the accessibility shouldn’t do something harmful to the business itself.
Reasons a feature may need an exception
- Content is part of a scheduled (and expensive) advertising campaign
- The feature is required as for an immovable government mandate
- A component is part of a greater sweeping change scheduled with partner organizations
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 that accessibility is a requirement and that a VPAT with validation 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
- 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 self validation.
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 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.