Scaling Web Accessibility at Facebook

This is my fourth session from the first day at the CSUN conference.  This session “…covers Facebook’s work over the past year to scale web/mobile accessibility across the company’s large engineering department.”  Description comes from the conference event guide.

Presenters:

• Jeffrey Wieland
• Ramya Sethuraman
• George Zamfir (@good_wally)

 

RESOURCES

•  facebook.com/accessiblity
• facebook.com/help/accessibility
• @fbaccess

 

BACKGROUND:  how to scale accessibility in a large engineering environment.

• Complexity:  Each platform has different considerations
• Awareness:  products need to know what do for accessibility
• Speed:  need to integrate accessibility into the process

 

JEFFREY’S SEGMENT

Accessibility team came into existence by recognizing that users were using AT to mediate their relationship with the product.  Jeffrey appealed to user interface engineering (UIE), which is the front-end team that builds all the core components of the product.  These components are similar to the design pattern library work that LinkedIn is doing.

Unfortunately, most Computer Science graduates do not have much exposure to accessibility.  So, accessibility has been integrated into the core training regimen at Facebook.  If it’s a part of the core training, then it sends a message to the developers that it’s important.

Testing matters, so we’ve invested in something called an “accessibility nub” which is essentially a flyout menu (built in-house) that allows developers to toggle looking for best practices.

Centralizing documentation and best practices has helped engineering review things “in-context.”  Contextual links to this resource have been embedded wherever needed.

These steps have give us the ability to “have more hands on deck” with respect to accessibility.  This has grow the number of developers working on accessibility fixes to over 80(!)

A number of ambassadors have been enlisted to help evangelize accessibility internally.  We also have channels by which we communicate with our users (see resources section above)

 

RAMYA’S SEGMENT

Ramya began her segment by describing the alt text issue she had posting a picture of her one year-old daughter trying yogurt for the first time (very cute!).

Caption generator:  takes bits of metadata about uploaded photos and auto-generates a caption for the user.  Ramya demonstrated how this sounds with VoiceOver, both before and after using the caption generator.  Addition of  metadata elements like location photo was taken was very effective!

Semantic Structure has been added via headings and landmarks.

The core components library contains controls like buttons, links, images, etc.  Accessibility is built directly into these components.  Dialogs now have keyboard enhancements, with appropriate labeling.  Focus cycles through dialogs.

Keyboard Shortcuts:

• j/k keys are used for moving focus forward and backward, respectively.
• “c” key is used to comment on a post
• “s” key is used to share the post,
• “o” key is used to open attachments like photos
• “q” key to chat.

High contrast mode is also available now.

A lot of effort was put into making the desktop view accessible.

 

GEORGE’S SEGMENT

Quality Assurance:  all is done with scale in mind.  It all started with a spread sheet, and testing was done in an ad-hoc fashion by a very small accessibility team.  In order to scale it, it had to be spread to the entire team!

We now run standardized regression tests on a regular basis for each platform.  We also do user testing with people who have disabilities.

QA (test run) > ProdOps (triage & assignment) > Eng (improvements)

Where does the A11Y team fit into the above?  It fits in wherever it makes sense.  Across products & platforms, and runs on auto-pilot.

“If you build the product, accessibility is YOUR responsibility.” It’s just another form of code quality.

 

JEFFREY’S SEGMENT

Mainstreaming accessibility is something that we want to pursue at all levels.  One of their front-end engineers was working on the web messenger product, and when asked if he’d tested with a screen reader, his response was “what’s a screen reader?”  This is not his fault, because he was not exposed to accessibility during his education.  So, Facebook is now partnering with PayPal, Stanford engineering to get students to think about accessibility.  This will help to build awareness.

 

Q & A SEGMENT

Question:  how much of the data associated with the photo example presented earlier is auto-generated versus user-supplied?  Answer:  it has be user-entered content.

Question:  how are you testing for high-contrast mode?  Answer:  well, it’s complicated…(I didn’t catch all of the answer).

Question:  are the testing links you talked about generalizable for use by public testers?  Answer:  not really, but we’re working on it.

Question:  how do you track focus when using keyboard shortcuts?  Answer:  we return the currently active element.

Question:  have you been able to document whether or how the accessibility features have been implemented?  This is a big challenge, quantifying the impact your work has made.  We’re doing a lot around measurement, which helps improve where we focus our efforts.  We do read all of the feedback we receive, both positive and negative…please be candid with us!

Question:  where does the role of the engineer start and end?  Where does design fit in…how do you get accessibility baked in?  Answer:  we’re still defining how this works Facebook.  Some things engineers should absolutely be involved with, notably focus and readback.  Things get trickier when building more dynamic and collaborative tools.  George indicated that their designers were ready to roll straight into implementation and pretty much ate up everything he gave them.

Question:  do you need to activate keyboard shortcuts somewhere in the user preferences?  Answer:  no!

Comment:  I wanted to mention that I submitted a JavaScript-related accessibility bug recently and got a response THE SAME DAY.   Very great high-touch service (this got some applause).