Pivoting to fully remote accessibility testing

Five months into the pandemic w/ no finish line in sight, temporary changes must be reassessed and made permanent to improve productivity.

We are now five months into the pandemic. That is enough lived experience to have determined that:

This isn’t ending any time soon.
The initial elation about work from home has transitioned in many departments to ennui, increased meeting overhead, and more extended hours combined with plummeting productivity.

Most accessibility managers have at least some work from home experience with some of their team members. People with disabilities are more likely to have requested part-time or full-time WFH as a reasonable accommodation. However, those were individuals who wanted to WFH and, more importantly, emotionally invested in WFH. Also, these WFH choices were usually executed with a fair amount of planning and could be reversed if they didn’t work out. Now everyone is WFH whether they want to be or not. To make that even more complicated, with the economic situation still uncertain, asking for additional resources to make up for the almost universal productivity drop is mostly a non-starter.

More importantly, many high-tech companies are signaling that they will allow employees individually to determine whether they want to continue working from home even when the pandemic is over. That makes sense, given that everyone’s personal situation is different. One thing is clear — managers may have limited to no say in that choice in the future.

Temporary, stop-gap measures implemented at the beginning of the pandemic are starting to show cracks. What should the well-intentioned accessibility manager do?

Use accessible collaboration tools

Collaboration tools are essential to having a distributed workforce. However, very few of them are accessible to people who are relying on assistive technology. When it is likely that you have people who use assistive technology on your team and you can’t assume they will have someone available at their home who can help them, accessible collaboration tools are the only option.

Accessible collaboration tools

Slack (referring to channels only, see comments below about Slack voice and video calls).
All Microsoft tools, including the common ones (Word, Excel, PPT) and less common (Whiteboard).
Anything in the G Suite (Docs/Sheets, and Jamboard in particular).

Some Atlassian tools such as Trello and Confluence have reasonable levels of accessibility but are not entirely accessible.

Accessible if you buy plugins

JIRA and Sharepoint

Inaccessible collaboration tools

Pretty much everything else, including Figma, Miro, and Dovetail. If you don’t know if a tool is accessible, look for an accessibility statement. If they don’t have one, chances are they aren’t accessible.

If you find yourself being asked to use inaccessible tools of any kind, a discussion with D&I, your reasonable accommodations team, and your procurement department should happen to stop increasing the employee accessibility debt. All procurement teams should be including accessibility in their procurement evaluations.

Use accessible video conferencing

Accessible video teleconferencing for groups in order of most disabled users’ preferences: Zoom, Google Meets, MS Teams. Zoom has a nice feature called “breakout rooms.” If you have a meeting where someone needs extra assistance — like you HAVE to use an inaccessible tool, but one of the team members is a screen reader user — you can put the person with vision loss and an assistant in the breakout room to do the work together, then rejoin the main call when they are done.
Slack is keyboard and screen reader accessible but hard to use for people who require magnification and does not support captioning. Anecdotally, I have had a lot of reliability issues with both native Slack voice and video calls. Slack now has an “integrate with Zoom” option that seems to work much better.
FaceTime is the preferred platform for 1:1 calls with ASL users.

For a fantastic article that goes into each teleconference platform’s accessibility details in minutia, check out this article written by my friend Claudio Luís Vera.

Of course, video teleconferencing is not accessible without captioning. Other than live captioning (which almost everyone supports at this point, but can be expensive) Zoom has multiple auto-captioning options, including rev.com, otter.ai, and Verbit. MS Teams and Google Meets each has its own auto-captioning solution. The only reason I ranked Google Meets higher is it is free and less clunky (at least for me, a keyboard-only user) to use.

Make sure everybody with vision loss has access to sighted assistance even if they live alone

With everyone working from home, you have zero guarantees that everyone with vision loss has access to sighted assistance at home. They may live alone, or spouses/children who are also at home may have their own responsibilities and not be able to assist them.

VMware has acquired “Be My Eyes for work,” which allows VMware employees who sign up as volunteers to assist other VMware employees who need assistance. Smaller companies who are not worried about confidentiality can use the general Be My Eyes app for free, or reimburse employees who use Aira.

Forget about pooling hardware resources

A common pre-COVID approach to save accessibility budget was to buy a “library” of hardware resources for each location and share amongst team members. Surprise! Your number of sites just went up exponentially with WFH. Given this limitation, you have two options:

Buy everyone their own comprehensive set of laptops, mobile devices, and AT, including a Mac, a PC, an iPhone, an android device, Tablets, keyboard, software licenses, and a switch. If you work for a small company, buying everyone their own set of hardware may be more simple because you can buy used equipment. This is actually a good approach because older equipment is more representative of what people with disabilities use. Most larger companies ban this approach because of IT/security concerns.
Reorganize your testing to pair up “testing buddies” (one with a Mac, the other with a PC, for example) and team test. This approach relies on the testers to coordinate between themselves to sort out which tickets are platform-specific, and which are coding errors that show up on all implementations. This may lead to some inefficiencies or even conflicting recommendations if both people document the same issue.

Check on home setups

People with disabilities are more likely to be in lower socio-economic categories which means they may not have great internet access at home. And while most people have gotten to take their laptops home, they may need larger monitors, good chairs, risers, or better headphones. If individuals had ergonomic modifications in the office, make sure they get ergonomic checkups at home too. This will help avoid downtime caused by repetitive stress or other preventable ergonomic problems.

Declare a single source of truth for all accessibility defect logging

It doesn’t matter what the single source of truth is, as long as there is only one. This concept was important pre-COVID, but it is essential now that we are all working in different locations. From least to most reliable, the approaches you can take are:

Individual Excel files are a terrible way of tracking defects. They are out of date as soon as they are emailed.
An Excel file shared through Google Drive, or OneDrive is a slight improvement, as long as you control edit permissions carefully.
A Confluence page is an improved approach over excel files.
A single accessible bug tracking system is the best approach, using agreed to labels to make it easier to sort on WCAG 2.0 defects or color defects, for example, for future analytics purposes. Because JIRA ticket creation is inaccessible without the plugin referred to above, AT users should use excel to record their individual defect details, upload those sheets into JIRA, then move the sheets into an “obsolete” folder (or delete them, depending on the electronic document retention requirements for the given company). Once in JIRA, AT users should be able to view and edit the defects going forward. I have heard rumors that Atlassian is fixing this issue shortly, in which case this workaround should stop as soon as you have the remediated version installed.

Office Hours and other ways of blocking time

Holding accessibility office hours is a powerful way to reduce developers from interrupting testing time. Make sure you:

Rotate responsibility — Few people love doing office hours on a permanent basis.
Make sure you cover time zone differences if you have developers in different timezones than the testers

Consistency is a significant need when providing accessibility advice to developers. Consistency will be improved if you push developers to use the published information first before reaching out to the accessibility team, and you establish the order of which you want developers to reach out to you. At VMware, that is:

Start with Confluence (developers review the accessibility pages which can be found from our Disability Hub).
If there is nothing on Confluence, then the developer moves on to searching the relevant Slack channels.
If nothing turns up in written resources, check with your local accessibility champion — VMware is just rolling this program out, we hope to have one or more accessibility champion on every product team.
Attend Office Hours (if the question is not urgent)
Start a new Slack thread (if the question is urgent).

We are discouraging developers from emailing questions since we have hundreds of people on the accessibility slack channel, and it is good to be able to see other people’s problems and recommended solutions. Anything asked and answered at office hours gets posted to the Confluence pages.

In the second week of the pandemic, I started blocking out 3 pm to 5 pm California time to “get work done” that was best accomplished without being interrupted. That mostly includes research and preparing decks. I honestly wish I had done it before the pandemic.

Make sure the team has everyone’s “care and feeding“ instructions

Some people work better over the telephone, others do better in email, and a third group works better by text message and Slack (because they go nowhere without their mobile devices). Some people are OK at multitasking, others are not. The days of being able to stop by someone’s office if they don’t respond to an email, or catching them at the coffee pot or at lunch are gone for a while, so it’s important to understand (and make public) the communications styles of each team member.

This trick is as simple as asking people what their preferred communications channel is and what their preferred platform is. That way, you aren’t asking them to test on a Mac if they are primarily a PC user (you can if you are desperate, but make sure you take the “not my favorite platform” factor into account for guessing how long the work will take). For example, my oral deaf daughter can talk on the phone, but it is difficult. She is also a rabid Mac user. Like most people with hearing loss, she vastly prefers text messages.

Set a team “service level agreement” for returning messages

It is not a good look when you are late delivering something because you couldn’t get ahold of someone who held a gating, critical piece of information. That is more likely to happen when you can’t do a cube drive-by to ask someone what is going on with the information you are waiting for

If Slack is one of your communications channels, get good at updating your emoji to indicate whether or not you are interruptable, and if not, how long you will be away.
Set your out of office reply on your email for more prolonged absences.

Publishing SLAs is also an excellent way to remind developers that they don’t get to reasonably expect code to solve the question they are asking six minutes after the post their questions. That will hopefully help reduce spurious escalations that are always a time sink-hole.

A few important final side notes:

Remember that each member of your testing team has an intersectional personality. Disability might be one aspect, but they will be impacted by being a parent, having aging parents, racism, gender discrimination, homophobia, and pretty much anything that a non-disabled employee will face. Recognizing when they are stressed and having a relationship that is trusting enough that they will tell you they are stressed and what they are stressed about if you ask them is something that is important to *every* manager’s success.
Don’t expect all your team members to be excited about being on video all day. As someone born with a craniofacial deformity, I really don’t like looking at myself. That was never an issue when everything was in person because I was focusing on the conversation, not staring at a screen of my picture while talking to people not physically present. People with anxiety and other mental health challenges might also prefer to have their video turned off as a default.
Frequently ask “is there anything I can do to make your job easier?” Then follow up, starting the reasonable accommodations process if necessary at your company.
Review training and onboarding for accessibility. Since in-person options are no longer available, there is likely to have been a lot of recent changes that may not be accessible.