important. Let’s do something about it.
Just as the title says, I’m here to talk to y’all about accessibility, why it’s super important, how we’re dealing with it at Vox Media, and I’m also going to leave you with some tips to start implementing it in your work.
Senior Front-End Engineer @ Vox Media
My name is Ally Palanzi and I’m a senior front-end engineer working on our content publishing platform at Vox Media.
At this URL you can find slides, if you want to follow along. I'll also tweet this!
How many of you include accessibility in your work flow currently?
So what is accessibility anyways?
Accessibility (a11y) refers to the design of products, devices, services, or environments for people who experience disabilities.
In 2001 the World Health Organization redefined disability as: “a mismatch in interaction between the features of a person’s body and the features of the environment in which they live.”
Our work can
create or remove mismatches in interaction.
As designers, developers and people who make stuff, our work can create or remove these mismatches in interaction
The impact of disability is radically changed on the Web because the Web
removes barriers to communication and interaction that many people face in the physical world.
By designing with disabilities in mind, we create better products for
By designing with disabilities in mind, we create better products for everyone.
It’s important to not think of disability as something that only effects a subset of users. It’s not something you can tell from your analytics, you can’t see who’s using a screen reader on your webpage, and there’s not a great way to test for if folks are only using keyboards to interact with your site.
Disability affects all of us at some point.
Disability can effect anyone at some point in their life, or even all within a day.
Disability can be permanent, temporary, or situational.
A user who might be using your website with a mouse one morning could have a child in their arms later that night, and only able to interact with your page via a keyboard.
Ok, but why should we
a.k.a. what to tell your boss
So, I get it. It can be hard to advocate for accessibility when you don’t have analytics to prove progress or improvements, but you’ve just gotta trust the facts.
It’s better for business
Design for older users
Building accessible products and websites is truly better for business.
A lot of thinking about accessibility feeds into other best practices such as device independence — your product should work across devices.
your product should be usable,
older users should be able to use your site,
and a word all important execs and clients like to hear: SEO. If a screen reader can access your site properly, so can google’s indexing crawler.
Case studies show that accessible websites have better
search results, reduced maintenance, and increased audience reach.
W3C Accessibility Overview
Case studies show that accessible websites are just better overall — better search results, less maintenance, and increased audience reach.
social inclusion, allowing us to hire more diversely & reach a diverse audience.
Everyone should want to hire more diversely & reach diverse audiences — accessibility supports social inclusion
Scary legal things!!
Also scary legal things! Companies like Netflix and Sweegreen have already experienced lawsuits for having accessibility issues.
Things like creating internal tools that employees are required to use to get their job done, if inaccessible, might mean that you can’t hire as diversely as you should, or it might mean you’re disadvantaging disabled employees to do their job.
This is especially important for us at Vox as we create tools for our reporters to publish content on our websites.
Many countries are recognizing and acting upon the need to ensure access to the web for people with disabilities.
Many countries are recognizing and acting upon the need to ensure access to the web for people with disabilities.
A common approach throughout the world is for nations to adopt the
Web Content Accessibility Guidelines.
WCAG is developed through the W3C process & explains how to make web content more accessible to people with disabilities
Section 508 of the Rehabilitation Act means that all users, regardless of disability status, can access technology.
It is a mandate for government agencies, federally funded non-profits, public colleges and schools to pass a certain standard of accessibility.
World Wide Web Access: Disability Discrimination Act Advisory Notes requires equal access for people with a disability where it can reasonably be provided.
Similarly to the US 508 compliance this mandates for government, banking, and education sites to be accessible.
EU Charter of Fundamental Rights Article 21 prohibits discrimination based on grounds of disability, among others.
WebAIM World Laws
Each country is slightly different, but it's important to be aware of what accessibility laws pertain to your work.
And if this still doesn't convince your stakeholders...
Ask for forgiveness later
Build accessibility in! No one is going to be mad at you for making your products accessible (I hope).
How we’re solving a11y at Vox Media.
So, like I said there’s a lot of reasons to care about accessibility.
At Vox, we’ve grown a lot over the past few years. We’re building lots and lots of tools daily.
And it’s not something we’ve officially ever considered, until now.
Our foray into accessibility didn’t really get started until
We really didn’t get started until just a few months ago, but we’re already seeing big changes across the board.
We’ve always had advocates for a11y.
An accessibility slack channel was created in early 2015.
We’ve always had advocates for Accessibility. In early 2015, one of my coworkers created this slack channel where those of us who were interested would drop links and share knowledge. It took a while for us to get much past that.
Lots of talking.
We talked a lot, trying to figure out just how we could really start including accessibility in our work-flow.
At Vox Media, we have a yearly hackathon that we call Vax where we can work on pretty much whatever we want.
EXPLAIN MINI VAX
Realistically, we couldn’t take too much time away from our day to days to get this done.
So we had two days.
We decided we wanted to have some sort of training or at least hear from other companies who have implemented accessibility practices.
So we reached out to Viget!! And Jeremy Fields came up to our offfice for an afternoon to talk about all things accessibility.
After digesting all of what we learned, we spent the entire second day writing documentation.
We wrote a lot of docs!
A lot of documentation.
We decided to break our docs into role specific guidelines that way it would be simpler to spread it across our team with specific todos depending on the role.
We came up with some guiding principles to consider when thinking about accessibility:
People want to access our content and use our tools; let’s make it easy for them.
We don’t make assumptions about our users.
As I mentioned before it’s really difficult to tell what disabilities may be affecting your users.
This is where the industry is going. Get on board or get left behind.
Accessibility is everyone’s responsibility.
We didn’t want to be known as the “accessibility police” so we wanted to ensure that while reading these documents, everyone understood the importance.
We shared internal guidelines
This turned out to be super successful! We spread them around to our teams and people read them and loved them.
We wrote articles on our editorials internal documentation website
We ran knowledge shares
We began giving presentations to any team tha would let us
We began to incorporate it into
Keeping people accountable
Integrating accessibility into QA process
Treating it as any other feature in a project
And we started some practices to keep people accountable like including a11y into our QAing process, treating it just as any other feature in a project and trying to celebrate wins where we could.
How can we share them with the world?
When we first wrote all of these docs, we had talked about open sourcing them however it was out of scope for the two day hackathon. Because of our successes with sharing it within the company, we really wanted to figure out how to share it with the world.
Lucky for us, it was nearing our yearly hackathon in July, Vax.
2.5 days figuring out the best way to open source our documentation
We spent two days in Chicago fleshing out our guidelines and figuring out what kind of way we wanted to share it. We considered just releasing documentation as is on a small stie but started brainstorming how we truly used these documents.
Our docs had been working out well for us, and we wanted to share them. Better yet -- we wanted people to contribute to them
One of my teammates, a designer, Sanette, had started including an accessibility check list when working on projects.
Because of how she was using these docs, we thought that a checklist builder might be useful for everyone.
So after two days — we launched acccessibility.voxmedia.com
We have the site divided into the same sections we created documentation for — designers, engineers, projects managers, qa, and editorial, and it allows you to select the items relevant to your projects and outputs a list for you to copy out at the end. It also includes tons of links to resources and tools.
We got a lot of love for it on the internet! And even a few open source contributions. This was exciting for us!!
Accessibility best practices* for designers & developers
*Not all, but some good ones.
Okay, so enough of that. I’m going to teach you something you can start using immediately.
Make sure there is enough contrast between text and its background color.
Don't indicate important information using color alone
Pair values of colors together (not only hues) to increase contrast
Design accessible forms
Fields should have labels that are always present, error messages should be clear
Build accessible forms
Always have labels, don’t rely on placeholder text
Labels should not disappear on form focus
Use fieldset and legend for larger forms like a checklist
<input id="name" type="text" name="name">
<legend>Select your pizza toppings:</legend>
<input id="ham" type="checkbox" name="toppings" value="ham">
<input id="pepperoni" type="checkbox" name="toppings" value="pepperoni">
Use semantic HTML
Limit div soup, strip unnecessary HTML elements
h1-h6 for content structure
Avoid skipping headings in the same sections
It’s okay to have multiple of the same heading on a page.
W3C HTML5 Semantic Elements
These landmarks help define specific areas that a user might want to seek out and can save them a lot of time.
<header> for role="banner"
<main> for role="main"
<nav> for role="navigation"
<footer> for role="contentinfo"
<aside> for role="complementary"
HTML document should have a language attribute
<html lang="en"> </html>
NEVER remove focus states from elements
Design better ones or leave them as-is
These should not be subtle – they should stand out so users can tell what item they are tabbing to
outline: none; //BAD!!!
Know when to use buttons vs. links
Linking to something outside the page? Use an anchor tag.
Performing an action on the page? Use a button.
Make links descriptive
“click here” vs. “click here to read more about Vox Media”
This is also helpful for SEO!
Write good alt text for your images, hide decorative images
<img src="catomg.jpg" alt="cute fluffy cat">
<img src="border.png" aria-hidden="true">
Accessible Inline SVGs
SVGs are often used as icons on interactive elements in sites. The SVG should have a title or description, then you can use the aria-labelledby attribute to tell the screen reader what element to use to describe the SVG.
Sitepoint Tips for Creating Accessible SVG
If an experience cannot be made accessible, create another route for assistive tech.
Maps, charts, graphs might be more accessible as HTML tables.
Support keyboard navigation
Users should be able to tab through the entire page
Don’t allow “keyboard traps”
Don’t hesitate to push back on inaccessible designs
Semantic html goes a long way
Don’t change default semantics
Okay this sounds like a lot. How do I
Testing best practices
Navigate the page with your keyboard
Add accessibility to your project checklist just as you would any other function or feature.
Include a11y in your device/browser QA process
Test early and often!
Trouble getting buy in?
Ask for forgiveness later.
Baby steps count, it’s not going to happen all at once.
Think about accessibility
early & often.
Semantic HTML + browser defaults go a long way.
Let’s make our work