Jesse Beach is a senior front end developer and a specialist in web accessibility. She currently works at Facebook on building web accessibility testing tools and improving the accessibility of Facebook's user interface.
In this talk we focus on her rich experience in "driving accessibility as a requirement" within various large and medium organisations and talk about how open source is the driving factor behind innovation in web accessibility technologies. Read on for more!
When I went through your online profile the first thing that grabbed my attention (besides your rich professional portfolio) was your short introduction: “I believe in information. It reifies our human experience”. I’ve also noticed that you’ve been initially studying linguistics in Germany, China, France to end up as a developer focused on web accessibility. What’s the common denominator between all these life experiences if you could draw one?
I think it comes down to empathy and compassion. When you study languages and the human capacity for speech and expression, it becomes very evident that we are always concerned with the same struggles and topics. I was taking historical linguistics classes when I was studying and noticed how people in the past had the words for things that we care about today like family, relations, food, activities etc.
Understanding that (despite surface differences) there is a universality to the human experience and thinking about these differences in terms of the abilities of individual humans is key to realizing that underneath it all we’re all looking for connection. The technology we use shouldn’t limit us from finding that connection.
You’ve worked in companies of various sizes - ranging from small to medium. You’ve been your own boss, but you’ve also been working for the big players such as Oracle, Acquia and now Facebook. These companies have different approach to web accessibility. Judging by your experience - what are the best practices towards web accessibility within a company, no matter its size and structure?
Every business has this tension: first of all it has to make money to survive. I understand that every business fights this struggle to allocate resources as efficiently as possible to build a product and sell it at a margin that allows you to pay the people that work for you and to do more. Often our technology makes it easier to produce something for the majority and increase the margin of profit. That's one of the two reasons that (when we think about accessibility) the focus within an organization often falls short of the expected result.
So one of the reasons is money and the other is just education. If your developers, designers and product managers understand how to address the means of the non-majority population in their user base (and to do so quickly at a low cost), then I think they’re more likely to build that into their process, than if they don’t understand how to accommodate and build for these particular interaction styles. It really comes down to the knowledge and the amount of resources that a particular business has to put in place.
I’m very much a pragmatist when it comes to accessibility. In the same way that I don't know how to write a driver for a particular piece of hardware, I don’t expect every product engineer in an organization to understand how to address accessibility needs. That’s just the reality of the world we live in - people specialise. It’s our responsibility to make accessibility support so easy and automatic that we don’t have to train specialists - we just get it for free in the same way you get rounded corners in CSS by using border radius. Accessibility needs to become that easy and automatic, then we’ll see it taken up and provided for at web scales - not just by companies that can afford to do it because they’re making the margins.
You’ve been responsible for “driving accessibility as a requirement for all front end development in Drupal core”. What are the lessons learned in making web accessibility a priority in such a large scale project as Drupal 8?
I think Drupal did an excellent job in considering accessibility. Our community just understood that it had to be addressed and considered throughout the process. I was never told by anyone in the Drupal community that we would get to accessibility when the project was nearing completion or when we solve any other big problem. It was simply considered a big problem to solve throughout the development cycle.
For other projects I would simply counsel that accessibility would be presented as a gating concern. You don’t release the product unless you’ve addressed the gaping holes in accessibility support in your core infrastructure and your ecosystem.
I’ve been introduced to your work by the way of Quail - the accessibility checking engine that resides inside our Accessibility Checker. Could you briefly tell me how the whole project started, were there any breakthrough moments and what is the future of Quail?
I met Fred (CKSource CEO and CKEditor project lead) in Prague in 2013 - the year we had the DrupalCon there. Back then we had incorporated a different in-place editor into Drupal core and the project wasn’t as fast as we wanted. I had spent some time ripping it out of core. We eventually settled on CKEditor as the best WYSIWYG editor to ship with our core product. It was the first time Drupal shipped a sanctioned WYSIWYG editor.
That relationship brought together the inclusion of Quail into Accessibility Checker for CKEditor. At the time Quail was one of the few open source accessibility checking platforms with the architecture that was capable of being included inside of CKEditor.
I’ve spent 2015 completely refactoring the basic infrastructure and releasing version 3, so now Quail is built using Babel, which means we can write in ECMAScript 7 (depending on the modules). I refactored the infrastructure to use a modular architecture, so we can pull in pieces of code to Quail at the build time in a way that wasn’t possible previously.
The architecture of Quail represents what I think we need to move towards in the general open source space for accessibility conformance testing. There are other projects like aXe that I think are moving in the right direction. I think we’re moving towards a space where we have a common test pattern, which we can include in various platforms. I want Quail to be a kind of a model for these various open source projects and the way we can build a contribution space (much like the Drupal module contribution space) for building conformance tests that can run on any particular platform.
You’re currently working at Facebook and I can see that your accessibility team is taking it to a whole another level. In 2015 we could read about your plans to create a tool that can enable the blind ‘see images’ on Facebook. One of the Facebook Accessibility updates mentions your Teach Access initiative, which is all about raising awareness about the understanding of basic accessibility issues, concepts and best practices. What’s the future of web accessibility according to Facebook and why it’s such a priority to a company which already has more than 1.6 billion active users per month?
The core mission of Facebook is to make the world more open and connected and it’s impossible to connect the 7.5 billion people in the world unless we’re also connecting those people with disabilities. If our product doesn’t meet the needs of people with various disabilities then we will fail on our mission. Therefore it’s a top priority at Facebook to support accessibility.
When it comes down to it at Facebook’s scale there are tens of millions of members that have vision impairments - from impaired vision to blindness. We also consider hearing disabilities and tactile disabilities. The human range of ability is fairly wide and our mission is to address all human connection. The Accessibility team at Facebook is a part of core Facebook mission. We’re working with the biggest teams in the company to make sure that our flagship products are there for everyone.
I know you've been attending CSUN Technology and Disability Conference in San Diego where you were one of the panelists speaking about Open Source and Accessibility. If you could enumerate just a couple of trends or issues that will shape the future of Web Accessibility, what would these be?
The major trend that I picked up at CSUN is that web accessibility is becoming a mainstream concern amongst front-end developers. The number of attendees that I’ve met who are working in engineering departments and not in policy or QA or legal departments really struck me. I have a feeling that there are a number of developers who think about accessibility from the engineering standpoint. It feels to me like we’re reaching a critical mass of folks who are going to start creating solutions - the third wave of web accessibility.
Other trends I’m noticing is that large companies like i.e. Google (who had introduced one of the most interesting product reveals during CSUN) are really investing in web accessibility. That is really encouraging. The focus is shifting towards innovation, rather than simply meeting the guidelines and conforming to legislations. Something like automatic alt text on images is a vastly different approach than simply making a webpage accessible to a screen reader. Don’t get me wrong - that’s an important thing to do too - however when you’re talking about a billion photos uploaded per day, we’ll never get human beings to write captions for all these images. We have to start thinking about these problems in terms of scales of millions and that requires a different approach to the problem.
You can read more on the topic of Web Accessibility in our If You're not Thinking About Accessibility, 5 Tips on How to Improve Accessibility When Creating Your Web Content in a WYSIWYG Editor, Commercial Benefits of Accessibility and Accessibility, usability and SEO go hand in hand blog posts.
In order to save your time and make sure that you implement proper accessibility standards on your website, we have created the Accessibility Checker - the first tool that enables you to check your content for accessibility issues and fix them before you go live.
It is built upon three key elements:
- User interface optimized for quick problem solving
- Flexibility allowing you to use the accessibility checking engine of your choice
- Quick Fix feature allowing you to eliminate common problems fully automatically