Visual Studio Toolbox

Tips and Tools for Making Accessibility a Developer Priority

Web and application accessibility isn't just a nice thing to do. It makes your work available to a bigger world of customers ... and may be a legal requirement for some projects.

Let's talk about building accessible applications and web sites. For the most part, when we talk accessibility, we're talking about making your work available to people with low vision or blindness (though there are other aspects to accessibility). According to Blindness Statistics from the American Foundation for the Blind:

"Findings from the 2012 National Health Interview Survey (NHIS) Preliminary Report established that an estimated 20.6 million adult Americans (or nearly 10% of all adult Americans) reported they either "have trouble" seeing, even when wearing glasses or contact lenses, or that they are blind or unable to see at all."

That's a lot of people who may need a little help using your application. Fortunately, there are a lot of tools, some built right into Visual Studio, that will make the job a lot easier.

There's a lot to learn, though, and it's going to take some extra time and effort on top of the not-always-easy job of writing, testing, and shipping your software. So why should you make the extra effort?

  • It's good business sense to make sure customers can include the over 20 million people with low vision.
  • It's the right thing to do.
  • For federal contracts, accessibility may be a requirement under Section 508 of the Rehabilitation Act of 1973.
I think it's also an interesting engineering and user experience problem to solve.

What Is Accessibility?
Much of the time, when we're talking about accessibility, we're talking about making applications or sites usable by people with low vision, but it also includes incorporating support for other kinds of assistance technologies. The ability to accommodate high-contrast screen coloring, magnifiers, and screen readers is important, for example. But also consider alternative paths for accessing commands: Think about how frustrating it was last time your mouse died in the middle of trying to do some work!

A good place to start learning about accessibility is the Why Accessibility Matters page of the Stanford Online Accessibility Program. This site provides great checklists and resources for incorporating accessibility into your project. And it's not just technical requirements -- the SOAP site also includes information on the accessibility related roles and responsibilities for your project team.

The W3C also provides extensive information about Web Accessibility, including the crucial Web Content Accessibility Guidelines (WCAG), but also details on accessibility for rich internet applications, authoring tools, and more. If you bookmark only one page for accessibility resources, make it this one: Web Accessibility Initiative (WAI) Resources.

Google's accessibility project provides an excellent Introduction to Web Accessibility course that walks you through both a better understanding of the problems faced by users and the specific steps you can take to address those problems.

Tools For Web Accessibility
Fortunately, once you understand the requirements for accessible Web and application development, there are some excellent tools available to simplify the job.

Over at the The Visual Studio Blog, the post Improving HTML Accessibility with Visual Studio Extensions gives you a great introduction to using the Tenon HTML Accessibility Checker extension for checking accessibility in web pages and, really, any HTML-based user interface. Code for the extension has been put up on GitHub.

You can also use the Tenon.io Web service directly for Web accessibility testing and reporting. There's a 30-day free trial period and monthly or yearly subscriptions at various levels from individual users to enterprise accounts. Tenon also provides links to additional testing tools on their Get Code page, many of which are open source projects.

WebAIM (Web Accessibility In Mind) provide training, site evaluation, certification, and technical consulting for accessible development. They also provide the free WAVE Web Accessibility Tool, which is an online site checker, and WAVE Evaluation Tool Chrome extension.

RampWEB's Section 508 Toolbar is designed for in-browser accessibility testing for Internet Explorer and Firefox. A bit dated now, but this toolbar may be helpful if you have to support older browser versions.

A more up-to-date option is Web Accessibility Toolbar (WAT) by The Paciello Group, which supports Internet Explorer 9, 10, and 11. Check the project GitHub page for setup details and documentation.

And while not a development tool, Cryptzone's Compliance Sheriff service includes Accessibility Compliance reports to check WCAG and US Section 508 regulations for Web accessibility. In addition, Compliance Sheriff can also check Microsoft Office and PDF documents, and includes compliance reports for Government of Canada Web Accessibility Standard, Accessibility for Ontarians with Disabilities Act (AODA), and XML Accessibility Guidelines (XAG).

Application Accessibility
Desktop applications also need to be accessible. Fortunately, Microsoft has long provided accessibility features in its development platforms.

The Magnification API has been around a long time and is really intended for developers of assistive software, but it's helpful for you to know that it's there and what it expects of your application.

Windows Automation APIs, originally designed with testing in mind, also include some vital tools for accessibility. AccScope lets you evaluate any application window, visualizing UI elements and the complete text of text controls. There's also a Narrator scenario that lets you test how a screen reader expresses your app interface.

UI Accessibility Checker (AccChecker) is an automated testing tool that checks your application for access by accessibility tools, accessible event generation, keyboard navigation, and screen reader transcription. It includes a graphical utility for manual testing, an API for automated testing, and a console interface for writing your own custom tests.

Making Your Environment Accessible
What if you need better accessibility as a programmer, or want some first-hand experience of computing with accessibility tools?

First off, Visual Studio 2015 has some built-in accessibility features that you can learn about in this MSDN Accessibility Tips and Tricks topic, which includes some hidden shortcut key combinations as well as useful shortcuts for toggling high-contrast mode and navigating dialog boxes.

John Mueller also has a two-part primer on accessibility in Visual Studio starting with A Visual Studio Quick Guide to Accessibility (Part 1).

ChromeVox is an extension for Google Chrome to provide in-browser screen reading capabilities. They also provide a handy ChromeVox Interactive Tutorial for learning about web navigation via the screen reader, synthesized speech, and keyboard shortcuts. I really like the tutorial approach Google is taking with these accessibility efforts. We're not all experts already.

Another free screen reader is NVDA by NV Access in Australia.

One of the leaders in accessibility solutions for Windows is Ai Squared, who offer the popular ZoomText screen magnifier and Windows-Eyes screen reader applications. Ai Squared also sell hardware assistance devices from large-text keyboards to ZoomText print magnification cameras. Also check out their SiteCues cloud-based Web site solutions for adding magnification and screen reader capabilities to your web site.

More Accessibility Tips
Here are a few more tips and tutorials I found particularly interesting:

Karl Groves has written a fairly recent, four-part series of articles starting with Everything you know about accessibility testing is wrong (part 1) in which he reviews the history of automated accessibility testing and how "testing practices take place at the wrong place and wrong time and is done by the wrong people." Starting with the third article, Groves looks at general automation and testing practices in web development and how integrating accessibility into the build-test workflow prior to deployment could help catch accessibility errors during at a point in the project where developers can more easily address them (and incorporate accessibility practices into their regular development process). Finally, Groves takes a look at the specific accessibility development and testing workflows that led to developing Tenon, which I discussed earlier.

Jim Thatcher has an older, twelve-part tutorial on Checking Your Web Pages For Accessibility that is worth a read through. While some of the specific testing tools are no longer current, Thatcher's overall process and guidance is still valid.

Good old MSDN Library includes an in-depth guide on Accessibility in Visual Studio and ASP.NET that covers the same ground as many of the other guides I've linked here, but with more focus on implementation details using Microsoft platform tools.

Finally, I can't help but finish with a few links on ye olde LYNX – The Text Web-Browser. You'd think that a text-only browser might be a particularly accessible browser, and it is a useful tool.

Cory Bohon demonstrates a few simple techniques for Using Lynx to Test Modern Web Sites for Accessibility over at The Chronicle of Higher Education. Be aware, however, that this is not the only testing you should do.

Steve Faulkner at The Paciello Group explains that doesn't work in lynx no longer means a site isn't accessible. Karl Groves hits the same point with his post Text-only is not accessible. Current assistance software can often accommodate Java, JavaScript, and CSS, so make sure your accessibility test suite uses current, real-world criteria.

Now you're armed with some great resources for making sure everyone can enjoy the applications and web sites you've spent so much effort building. Get out there and make accessibility a priority.

About the Author

Terrence Dorsey is a technical writer, editor and content strategist specializing in technology and software development. Over the last 25-plus years he has worked on developer-focused projects at ESPN, The Code Project, and Microsoft. Read his blog at http://terrencedorsey.com or follow @tpdorsey on Twitter.

comments powered by Disqus

Featured

Subscribe on YouTube