The accessibility team
Your accessibility team must have an entrepreneurial startup mentality. Your job is to introduce and build a market for accessibility.
Like any entrepreneurial effort, you will have to build relationships, sell the benefits of accessibility and engage in cultural study.
Consistent relationship building is everything
You’ll need people who can build long-term relationships to effectively build an accessibility team capable of meeting your strategic goals. If it’s a grassroots effort, your success will start with gaining leadership support for a dedicated team.
Win friends, not battles
Don’t bring people into your team who want to be the accessibility police. If your team is seen as an enforcement agency, rather than a helpful support, your mission will be more difficult because everyone will hide their work from you.
Can explain the strategies and tactics
Everyone needs to understand the strategic goals, including the key performance indicators (KPIs) and tactics being used to achieve them.
This understanding allows team members to make progress, report impact to leadership and show their effectiveness.
If you can’t report progress to leadership, your team will not seem effective.
Diligently uses a project management tool
There is no one right method of project management. Choose one and make it part of the team’s daily or weekly rituals. A single project management tool is central to the team’s work and collaborative efforts.
Don’t manage tasks and deadlines through email. Important communication needs to be placed in the system, prioritized and assigned to a team member.
Can distill requests into projects
Some team members, typically team managers, may default to email first for communicating work. The challenge with email is that it’s easy for it to exist as a shadow project management system where tasks become buried and forgotten.
Conversations that must be okay
The accessibility team will feel urgency and zeal behind the work. Recognize the scope of work to be performed and compare it to capacity team members can provide.
The team must be able and willing to have conversations around prioritizing work and defining capacity. You may come to a conclusion that a new project won’t start until others are complete or some work is deprioritized.
Responding to an “urgent” email conversation
Balance incoming requests with your in-process work. Don’t just react to an urgent request. Start by defining a due date and reminding the sender that priority work is currently being performed.
For example, you might reply, “Thanks for your email. This looks like something that we can define and prioritize in the project management system. When do you need a solution in your hands?”
The unexpected project conversation
Often team members receive requests without their capacity being taken into consideration. Reprioritizing tasks so that new work can fit is necessary, especially if their project list is already full.
Sample reply: “That’s an interesting idea and it sounds like a big project. Will this take priority over what’s already in progress? What is a definitive deadline for its delivery?”
What can sound simple on the surface might involve dependencies with other organizations, require approvals or budgeting, or generally be quite a bit more involved than it seems.
The unclear objective conversation
Some ideas need more discussion to determine if the work should actually be done. Indicators to look for include a definition of success, a particular audience or a due date.
Potential feedback: “This request doesn’t seem very defined. When can we discuss who will receive what deliverables and assign responsibility in the system?”
Defining a project in your system, with all of its required tasks, helps surface the true amount of work that needs to be done.
Differentiate between projects and programs
The commitment to projects and programs can be quite different.
Projects are measured by being done
A project has a definitive beginning and end. It will have a defined deliverable for an intended recipient.
For example, a project might be, “Create an automated reporting dashboard for leadership.”
- The deliverable is an accessible dashboard of charts and values.
- The recipient is leadership.
- It will have a process of tasks to complete based on a deadline.
- It will be considered successful upon completion.
Programs are measured by outcomes
A program is a collection of tasks that form a group of work that may be ongoing indefinitely. The recipient is the organization itself.
For example, a program of monitoring best practices across teams will report on compliance and correlate those results, resulting in a reduction of defects.
Some functions are both projects and programs
For example, creating an accessibility champions program will be big project that will define:
- Participant expectations
- Curriculum materials
- Levels of participation
- Integration with employee career ladder
- Rewards and certifications
Then for the program to be successfully implemented, team members will be responsible for the actual programmatic portion:
- Continually educating people about its existence
- Enrolling participants
- Tracking champion progress
- Measuring and reporting outcomes per product
Best practices monitoring
This work will make up a large chunk of your program reporting.
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
You can use this book’s guides as checklists of best practices. For each application, you need to establish a way to measure accessibility.
By comparing adherence to best practices with the corresponding level of accessibility compliance, you’ll be able to measure and manage the effectiveness of your program.
These need to be monitored, sometimes made part of onboarding training, surveyed and reported to leadership regularly.
- Design systems
- Component library
- Infrastructure and architecture
- Product owners/managers
- CMS authors
- QA testers
The precise information, and way it’s presented, should be a collaboration between your team and leadership.
Some leaders may want regular detailed reports, while others may want to simply know trends and times to intercede.
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.
- 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 (Ex: MagentaA11y.com entries)
- 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.
This is typically an easy metric to understand. An assessment will be translated to individual projects that can be monitored for completion.
It should take the form of defects remediated versus outstanding issues by severity.
A policy setting a deadline for remediation by severity can be tracked in relation to completion rates, generating a burndown chart that indicates the health of the initiative.
How to prioritize remediation efforts
Most full assessments include a manual and automated report organized by severity.
Severity is an objective scale. It’s important that teams agree on a uniform definition so that issues are remediated in a meaningful way.
- Any barrier that is impossible to overcome using expected interactions
- Any issue that makes it difficult to perceive, operate or use an application’s core functionality on the first try
- Features that are aggravating but can be worked through with some persistence
- Issues that can be bypassed with modest effort
Product teams may have difficulty processing and prioritizing the sheer number of defects, especially the automated report which may contain thousands of instances of invalid code.
The accessibility team must be prepared to help teams understand and prioritize the issues identified in the assessments.
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. For example, a high severity defect on a rarely trafficked page may take a back seat to a medium severity defect on a home page.
Legal risk and liability objectives also affect priority. A high severity color contrast issue might be remediated behind a medium severity screen reader issue, because there is higher complaint risk.
Focus on core functionality
Focus on your crucial customer flows. For instance, the ability for an online bank to access account information and transfer funds would be the most popular feature. Within that feature, prioritize defects by severity, starting with the manually detected issues.
The automated defects are incredibly helpful and should be corrected 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 experience. It’s simply indicative of sloppy code.
Be practical and reasonable
It’s impractical to expect teams to remediate all defects instantaneously. It will take time to prioritize and assign work to be completed.
Look for opportunities to alleviate remediation responsibility. For instance, if a non-compliant feature is already being rebuilt and will deploy in a reasonable amount of time, allow teams to remediate by replacement.
New defects introduced
Some product teams will interpret accessibility remediation as a one and done kind of task, then return to business as usual. This is why it’s important to validate remediation efforts with identical QA testing methodology as the first assessment and determine if new defects have been introduced.
Compliance rates with best practices
With best practices established, regular surveys of compliance can now be reported to leadership. This information can be correlated to individual teams and new defects introduced.
The expectation is that teams who are complying with best practices will introduce few new defects. If this is not the case, they may be misunderstanding or misrepresenting their compliance.
Any strategic goal KPIs
Your strategic goals should have KPIs attached indicating their rate of completion.
If you’re unable to make progress on those metrics, you can leverage the ability of leadership to encourage cooperation or enforce the policies to meet those goals.
As time goes on, you’ll build various programs with measurable outcomes.
- Best practices compliance
- Accessibility champion participation
- Expert guided lunch and learn attendance
- Vendor compliance rates
- Accessibility innovation center participation