George Zamfir appears as part of our Leaders Series, conversations with tech and media leaders about influential trends and topics in their field. George is a web developer and Toronto-based accessibility consultant. Prior to joining Facebook as an Accessibility Specialist, he ran his own accessibility consulting company, Good Wally, and spent several years as a Technical Accessibility Analyst at Scotiabank. George is one of the co-organizers of the yearly Toronto Accessibility Camp (@A11YCampTO) and the monthly Toronto Accessibility & Inclusive Design Meetup group.
As our lives become more digital, maximizing the accessibility of user interfaces and screens for everyone has become increasingly important. As an agency that interacts with startup software developers daily, we meet many that care about accessibility. One big problem: the development teams they work on might not consider it when building products.
What are easy ways that developers can start thinking about accessibility in their everyday work? I approached accessibility advocate George Zamfir to share some of his best tips to mark Global Accessibility Awareness Day.
In a web context, accessibility means that all people including those with disabilities can read, understand and interact with and contribute on the web. For individuals without disabilities web accessibility could become an issue with temporary impairment or with age and changing abilities.
Why should developers care about accessibility? For one, it’s now a legal obligation for organizations with over 50 employees in Ontario: as of January 2014, new legislation requires that all new websites and web content must be accessible.
With an aging population, accessibility will also impact the bottom line for companies as needs, rather than just features, increasingly shape consumer choices. For example, when it came time to choosing a cable provider George’s father, who has limited eyesight, made his choice based on which company’s e-bills were more legible.
As with Responsive Design, it’s also cheaper and easier to create accessible UIs from the get-go then redesigning them later. Responsive Design is a web advancement that has been both a champion for accessibility and something that has made non-accessible websites more accessible without sacrificing design or information architecture, since the core principles of Responsive Design were borrowed from Accessible Design (the principle of interoperability across browsers, for one).
It’s also worth looking at accessibility skills as a competitive advantage on the job market. “No matter where I worked, we always had a hard time finding people with accessibility knowledge, let alone expertise,” says George. “But the technical side of accessibility is mostly just a matter of revamping old technologies and legacy systems.”
Here are three easy ways that developers can start integrating accessibility thinking and testing into their everyday work.
1. Start with small wins.
Start by reducing the scope of accessibility work into 10-minute chunks. There’s a common misconception that developing for accessibility means creating a huge project with extra costs, resources and people. But anyone can get their first few manageable wins through simple testing.
A great first test: put away your mouse and tab through your interface to see if you can still use it. The keyboard test has the added bonus of being a good test for mobile, since a keyboard-accessible interface (usable without a mouse) also translates into being touch-available for touch screen devices.
There might even be unintended benefits of this test, says George: “When I was at Scotiabank we redesigned the online banking site to be accessible. Then we started noticing a huge spike in users logging into their accounts from tablets. At first it worried us because the site wasn’t designed for that, but it worked fairly well because the portal was already designed to be keyboard accessible.”
Some other “small wins” to start with: testing for colour contrast and colour blindess, or navigating your web page with a screen reader, a tool that reads aloud what’s written on the screen (like the VoiceOver tool built into the Mac OS).
2. Prioritize the functional over the non-functional.
First, an important disclaimer: prioritizing aspects of accessibility is very subjective. There is little way to know how many of your end-users have disabilities and what their impairment is; most people just don’t have good analytics on this.
There is one general principle, however, that might help developers prioritize if they have limited time and resources: choose the functional over the non-functional. For example, prioritize making your website keyboard accessible (functional) instead of sweating over the best alt (alternative) text for images of the perfect colours for colour blindness (both examples being non-functional). The reason is that keyboard accessibility covers more than just one disability (carpal tunnel syndrome, blind users and so on). The added benefit is that it’s much quicker for developers to understand and implement functional fixes, so it’s also a way to build some awareness.
3. Take advantage of automated online tools.
There are great free automated tools online any developer can use to test their website for accessibility. George highlights two:
Wave: On this website, plug in your URL and get a listing of accessibility errors or potential errors. If you don’t understand the error flagged, it’ll point you to the W3 guidelines that outline it.
FireEyes: A Firefox browser plugin that tests local websites for accessibility pre-launch. Provides a detailed and comprehensive report of accessibility errors. Send the error report to the WorldSpace public server and you can download it as an Excel or .csv file.
While these tools are a great starting point, George jumps in to note that it’s important not to lose sight of the bigger picture: “It’s important that people not get hung up on which tools are the best since in the end it’s really more important to make the first push towards valuing accessibility at the organizational level.”
4. Want to take it a step further? Be a champion.
Another approach to integrating accessibility into your organization, particularly for smaller companies with limited resources is finding champions within your development team. For example, at Scotiabank, one developer on George’s team had some knowledge and experience with accessibility, so they freed up some of his time to do some accessibility work and train other developers.
“Developers who start working around accessibility become champions within their own teams, but more often than not they also come to be recognized for their expertise and it becomes a competitive advantage in their careers,” says George.
While most organizations don’t have the resources of Facebook, the company actually provides an interesting grassroots example of how development teams can integrate accessibility into everyday work. The company’s goal was never to build a team to do accessibility work for the entire company since its variety of products (mobile, tablet, web, messenger, Instagram) made this a huge project.
The solution: scaling accessibility throughout the whole company. The team presented recently on their progress – a summary is online.
The Accessibility Team at Facebook was born as a movement within the organization two years ago. While researching the social network’s user base, the current manager of the team discovered a group of users that was accessing the social network with the help of assistive technologies. While Facebook spends lots of time, money and effort to make the user experience great, a cohort of people were experiencing it through an intermediary – the assistive technologies they were using. And so the Accessibility Team was created. Their goal: scale accessibility throughout the whole company by integrating accessibility processes and testing into all product teams.
This distributed approach has had a big impact on the development culture at Facebook. Developers that own a product or component also its accessibility, just like they own performance, design and other aspects. In other words, says George: “At Facebook accessibility has become just another form of code quality.”