Why this matters
Strategies set the big picture direction for your organization.
The scope of your strategies should be broad enough to encompass all necessary parts of the organization, including digital architecture, design, development, testing, release management, procurement, vendors and internal applications.
They are often tied to key performance indicators (KPIs) to provide some general measurement of success.
For example, reducing the number of complaint remediation fire drills from three per quarter to zero would be one indication of meeting goals.
Pro tip: Strategic goals ≠ tactics
Tactics are what an organization actually does to support strategies.
A common example of a strategic goal would be: “Identify and remove barriers to accessible development.”
To accomplish this strategic goal an organization might engage the following tactics:
- Hiring a consultant to study the software development process
- Study reveals QA testers have no requirement to test with a screen reader
- Adding screen reader testing as a requirement for deployment
- Adjusting timelines and budgets to allow for this new step
- Monitoring processes consistently for compliance and outcomes
These tactics would support achieving the strategic goal. The resulting outcomes would allow you to consider a strategic goal as on track.
Starter milestones
Don’t try to do it all at once. These beginning goals allow you to gain some foundational knowledge about scope and tools for communication.
Creation of a dedicated team and budget
Accessibility is not a one-and-done project. It will take consistent effort. It cannot be achieved by one person or by a part-time committee.
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.
- Product owner
- Product manager
- Account manager (if 3rd party application)
- Development manager
- Testing manager
Publish compliance policy standards
Just like you have security and accounting policies, accessibility needs a definition.
And yes, we all know WCAG is a bare technical minimum standard, but you do need a definable standard, and this is what we have.
Determining what accessibility means for your organization may vary by situation. Here are some helpful technical starting points:
Example starter compliance
- New minimum viable product (MVP) releases are WCAG level A feature compliant
- Core functionality products must meet WCAG level AA feature compliant
Over time, you’ll be able to step up compliance levels as teams gain competency and capacity.
Publish plain language rules
For general consumption, standards must also be written as simple accessibility rules a non-expert can understand and consume. Don’t make your plain language rules an overly verbose constitution or another form of WCAG. Think of it as a usable outline for discussion.
Compare accessibility efforts against peers
This information may be difficult to obtain, but, at a minimum, automated tests can be run against competitor products.
Strategic process changes
Reduce or eliminate accessibility fire drills
You don’t have a compliance program if your current method of staying compliant is responding to customer complaints. You have a fire drill program, which exhausts everyone and ultimately costs the company money and time spent in remediation.
Compliance reporting across all products
Before any remediation work can begin, assessments must be conducted to understand the current state.
Assessments must:
- Include a manual and automated assessment
- Use repeatable in methodology/approach
- Be consistent in scope
- Be customizable for different roles (ex: leadership will need a different report than product owners)
Establish priority and severity policy
Compliance reports without expectations for remediation timelines are just noisy data. The accessibility program must provide a standard method of grading a the severity of a defect and a methodology for prioritizing its remediation.
Manual and automated results
Defects will typically have a severity rating from low to blocking. Low severity defects tend to be annoyances in the experience. Blocking defects prevent the customer from completing an action on the first try.
Product teams may have difficulty processing the sheer number of defects, especially if the automated report contains thousands of instances of invalid code.
Focus on core functionality
Your first priority needs to be crucial customer flows. For an online bank, the most used features might be the ability to access account information and transfer funds. Prioritize defects by severity within these flows, starting with the manually detected issues.
The automated defects are incredibly helpful as well, but not every defect detected by an automated scan affects the customer experience. For example, an unclosed HTML tag is technically invalid markup, which is a defect, but it may not be affecting the customer. It’s simply indicative of sloppy code.
Be practical and reasonable
If a non-compliant feature is already being rebuilt and will deploy in a reasonable amount of time, allow teams to remediate by replacement.
Achieve compliance with existing products
This will often entail remediation or redesign/redevelopment of existing products. It may be necessary, even urgent, if there’s a customer complaint.
It’s not enough to tell a development team to meet a WCAG standard. If time allows, you may be able to upskill your development teams. If not, you will need a consultant or an appropriate resource.
Monitor accessibility compliance
Maintain your connection with leadership by delivering data, reports and trends, while proactively asking them to provide the visible support you need.
Manual testing performed by an accessibility expert
Get a true sense of how accessibility is affecting your customers by having an expert deliver an organized report of defects by severity, type and link to remediation techniques. This isn’t the same as a usability study, but it will illustrate the issues your customers actual experience.
An assessment generally delivers a report with the following described for each issue:
- URL where this occurred
- Summary (Ex: Sign in link is not focusable)
- Type of issue (Perceivable, Operable, Understandable, Robustness)
- Description of element or context causing the problem
- Severity (Blocker, high, medium, low)
- Assistive technology being used (screenreader, keyboard)
- Device (Desktop, tablet, smartphone)
- Browser (Chrome, Safari, Firefox)
- Platform (MacOS, Windows, iOS, Android)
- Link to remediation and testing technique
- Tester identification
- Unique ID for the issue
Automated tests from a uniform testing suite
Automated tests can find programmatic errors. For instance, it can pass a checkbox for having a label, but it can’t tell you if the label makes sense. It can flag an image for missing alt text, but it can’t tell you if it’s better that the screen reader ignores that particular icon.
Identify systemic barriers in the enterprise
This is where an outside consultant can be extremely helpful. They’ll have seen the accessibility compliance efforts and failings of multiple organizations and can assess the health of your processes, identify misses in standards and recommend changes.
Common systemic barriers
- Lack of diversity in workforce
- Cultural values incentivize quantity over quality
- Budgets and timelines don’t account for accessibility
- Content management system doesn’t support accessible publishing
- Weak accountability at various stages (design, development, testing, etc)
- Lack of accessibility core competencies amongst developers
- Absent accessibility testing procedures
Continuously measure teams for best practices
Directly survey each team for adherence to best practices, and be prepared to connect data to outcomes.
This can take the form of a self-reporting system. But a regular direct interview by the accessibility team will be more useful to build relationships.
Primary teams for monitoring
- Design systems
- Component library
- Infrastructure and architecture
- Product owners/managers
- Copywriters
- Designers
- Developers
- CMS authors
- QA testers
Set accessibility standards for vendors and partners
Web products today often rely on 3rd-party features, but those features must be compliant, too.
Much of the time this requirement is reduced to providing a VPAT (Voluntary Product Accessibility Template), which documents how closely a product complies with WCAG as it pertains to Section 508.
It’s produced by the vendor and there is no guarantee as to its accuracy without an assessment process.
It’s common for procurement processes to require an independent assessment to verify the VPAT, but it’s reasonable for a vendor to produce their own if they can demonstrate competency.
Cultural change
Adopt accessibility first design principles
By identifying weaknesses in processes and teams, it’s possible to achieve compliance. But we really want to change the way people think. This is known as “the shift left” — meaning accessibility moves to the beginning of any product plan.
Tactics often involve consistent communications, events and career related awards to incentivize change.
Establish an interactive accessibility innovation lab
The goal of the lab is for people to experience what it’s like to not feel disabled when using assistive technology. They should come away with an understand this is more than the right thing to do, it’s the best thing to do.
Budget for guest presenters
Adding an expert speaker from outside enterprise brings credibility to your program and events. It demonstrates the enterprise has invested in providing valuable content for teams.
The expertise of an external speaker, unweighted by the weariness of sagging cultural moral, can lend energy and weight to your program.
If teams have been skeptical or resistant to their accessibility commitments, you may find an outsider with a perspective formed from success elsewhere is easier to hear (and be swayed by).