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.
- Product owner
- Product manager
- Account manager (if 3rd party application)
- Development manager
- Testing 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: and 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 by role
Simply procuring training for all roles won’t solve your accessibility problems. Even when training is available it can be completely ignored or completed passive aggressively. Developers especially will expend enormous amounts of creative energy to get out of mandatory training.
Establish deadlines
Deadlines must be established for existing and new employees to complete training. This will be tracked as part of every team’s accessibility score. Training completion rates must be tracked as an accountability measure, but understood as correlative to a team meeting its commitments, not proof of its capabilities.
Allow testing out or equivalency
Some manner of equivalency or “testing out” of the training should also be available so team members with a solid accessibility foundation aren’t forced to take remedial training.
Pitfalls
Policy and regulations may make it difficult to mandate training, especially for contractors. Consult with your HR and legal counsel, as you may have to be creative in how training is distributed and tracked.
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 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.