Strategic goals

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.

Get direct help

Get a free 30-minute consultation to discuss your needs. I'll get back to you with a proposal and a calendar link to schedule a call in about a day.

Chat about strategic goals Building a continuous compliance program Product, UX, Engineering or QA consulting Tailored training and workshop proposal

Your information

Name Required Email Required Organization Required

What are your goals?

How can I help? Required

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

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).