Delivering Accessibility

Recently, VShift Managing Director of Technology, Dan Anderson, and QA & Accessibility Lead, Bill Fuchs, talked about accessible web design and how VShift develops highly usable websites. The discussion has been condensed and edited for clarity.

Q: Thank you both for making time for this conversation. Let’s start here: Accessibility standards are published. Is it hard to meet those standards?

Dan: Well, there’s a misconception in the market that accessibility “rules” are black and white. They’re not. There’s a lot of gray area, on purpose. WCAG [Web Content Accessibility Guidelines] is more like legal language – intentionally vague so it can be interpreted and applied to a range of situations. It’s directional, not prescriptive.

The challenge is to be faithful to the design intent while making the site accessible.

But maybe the fundamental challenge when it comes to WCAG is making a site accessible without “dumbing it down.” Anyone can “solve” accessibility issues with a sledgehammer: Just compromise your design and toss out whatever’s not accessible. Which, of course, is not ideal. The more challenging but ultimately more satisfactory approach is to be faithful to the design intent and still make the site accessible.

Bill: Another challenge is that we live in a multi-device world, with multiple hardware viewport sizes, various browser types and requirements, multiple screen readers and so on. Each hardware-software combination has characteristics that impact accessibility in a unique way.

Dan: One other complicating factor is ongoing “enforcement” – or let’s be nice and call it maintenance. You can launch an accessible site, but anytime you enable someone to create new content – or incorporate third-party content – you’re opening the door to non-conformance with WCAG, which ultimately means non-compliance with the ADA [Americans with Disabilities Act].

Q: Are there other common misconceptions?

Bill: There’s a basic misconception that a disability means total blindness or total deafness or paralysis. Those are permanent conditions. But what if you had eye surgery last week, or you fell and broke your mousing hand. People may acquire impairments with age, or partial or temporary conditions. Nevertheless, all need to be accounted for.

Another misconception a site owner might have is that “disabled people don’t use my site.” Which research – and common sense – will tell you just isn’t true.

Dan: One more big misconception, and this gets at the heart of how VShift approaches accessibility: Some people think of accessibility as an end-of-project event – like a quick QA before you launch. But that’s a bad approach: Everything is exponentially more expensive to fix after the fact. Accessibility must be baked into the project plan from the beginning. It’s part of the VShift toolchain. And that’s why for us, it’s a cross-discipline expertise.

You’re going to have a better result if you incorporate WCAG from the ground up versus going back and trying to fix a finished design.

Q: Talk more about that please – the idea of accessibility being touched by various disciplines throughout the project lifecycle.

Dan: I think accessibility planning has to start in the design phase because design-related accessibility issues are the hardest to remediate. You’re going to have a better result – a better product – if you incorporate WCAG from the ground up versus going back and trying to fix a finished design.

It’s the same principle we follow when designing a responsive or mobile-friendly site: You account for the non-desktop versions from the start. You don’t try to retrofit your “finished” design.

Bill: Design issues are more expensive, more time consuming and more difficult to resolve. They may require refactoring or some major effort. So, the best way to solve them is not to have them in the first place.

Q: Dan, a moment ago you referenced our toolchain. Please explain how that relates to accessibility.

Dan: Accessibility is part of a larger toolchain we call VShift Quality Management or VQM [pronounced “vacuum”]. VQM includes the sort of tools that flag, and in some cases fix, issues, assuming they’re straightforward. These tools are applied during both design and development.

Accessibility is part of a larger toolchain we call VShift Quality Management or VQM.

What we’re building towards is an end-to-end system that automates much of this process and prioritizes what issues to address and selects the optimal approach.

Q: Turning to one of the industries VShift focuses on … Are there special challenges for financial services with regard to accessibility?

Dan: The financial services sector is heavy on charts and graphs and illustrations. Those are inherently visual and among the hardest things to make accessible. For example, having multiple colors in a graph requires a particular ratio among all those colors to be accessible.

Bill: Some chart packages generate graphics that aren’t accessible. Or maybe all we’ve been provided is a .jpg of a graph. Any image, we recommend turning it into HTML, which is more easily accessed by a screen reader. But if for some reason the package doesn’t provide an accessible graphic, or if HTML is not an option, then we’ll add text to describe the content and point out the visual meaning, what the chart is conveying.

Q: That brings us to the topic of remediation … How does VShift do remediation for accessibility?

Bill: We’ve done a lot of evaluation and remediation of existing sites for clients. We actually built an evaluation system for tracking which automated and manual accessibility checks we’ve done. This tool guides an evaluator through all the necessary steps, for example: Have we checked all pages on screen readers, mobile phones and tablets, and automated tools? Have we manually checked every last requirement for the designated WCAG level? This way we log non-conforming issues, and this log enables the prioritization, approval and tracking of remediations. The log may also be provided to the client as documentation of the effort they’ve undertaken to comply with the ADA.

Q: And just so we understand, if a company doesn’t adhere to WCAG AA [the level used to determine de facto ADA compliance], what are the consequences? Damage to the brand?

Bill: Yes, one of the biggest risks is probably reputational – alienating customers, partners and so on. Especially because financial services is a basic human need: How could a bank or wealth management firm reasonably choose not to make their products and services accessible to everyone?

Dan: Individual reputation too. It’s a career risk to the product or site owner, to be called out as non-compliant, I would say.

Bill: And there’s direct financial risk. In the U.S., you could find yourself on the wrong end of a class-action lawsuit for violating the ADA. Outside the U.S. – say, Canada, the EU, Australia, Japan – it’s handled more from the regulatory standpoint. Typically, in those countries, the government fines the offending company, and they impose a penalty for every day the site remains non-compliant. It can get expensive.

Every discipline touches accessibility - strategy, UX, design, content, development and so on.

Q: I’ve heard you guys say that at VShift, everyone is in the accessibility practice. What do you mean?

Dan: Well, everyone is “in the practice” because our methodology guides us to consider accessibility implications at every development stage. Every discipline touches it – strategy, UX, design, content, development and so on.

Bill: And as a company, we firmly believe the principle that every site we build must be accessible to everyone. Many on our team feel almost a moral imperative to treat all users fairly and with respect. Simply put, we think it’s not okay to deliver a subpar experience to anyone. So, our people take it upon themselves to really dig into the guidelines and collaborate across disciplines to find solutions.