Posted by Laura.Lippay
[Estimated read time: 9 minutes]
(header image photo by H.L.W. from the Blind Photographers Flickr Group.)
39 million people are blind. 285 million are visually impaired. 15% of the world’s population — over a billion people — have some form of disability.
Disabilities can come in many shapes and forms: physical, cognitive, visual, hearing. How does someone who is blind check their email? How does someone who can’t hear decipher any of the tens of millions of videos on YouTube? How do disabled students keep an upper hand when all of their classmates are using the Internet for research?
Many use assistive technologies to help with these tasks. Screen readers are like search engines in that they can’t see the content of a page, and instead rely on signals in the code to navigate the web and understand the content of a page.
In this, and in two follow-up posts, we’ll explore the overlaps between optimizing for search engines and optimizing for screen readers and assistive technologies. But first, let’s get a better understanding of what screen readers are all about.
In the video below, Kyle Woodruff navigates the web without his sight, quadriplegic web user Gordon Richins navigates the web without his hands, and Curtis Radford navigates the web without his hearing. You’ll see that they still face challenges because of the gaps between what assistive technology (AT) can do and what is actually built in a way that can be accessed and navigated by assistive technologies.
Because he’s so entertaining (even has his own Amazon series), I also must introduce you to Tommy Edison, The Blind Film Critic. See how he’s easily using Twitter and YouTube with the assistive technologies built into the iPhone.
Give it a shot
Here’s a simple way to try something like this out for yourself right now:
- Open a Chrome browser
- Install the screen reader extension ChromeVox and enable it.
- For a better experience, utilize some of this ChromeVox help:
- Go for it. Navigate.
Optionally, you can also enable these more complex free screen readers on your device:
- VoiceOver on Mac OSX, iOS. User Guide. Shortcuts.
- NVDA free screen reader for Windows machines. User guide. Shortcuts.
Try any of these on your own website. How painful is it?
Do something about it
Consider going beyond simply being aware of accessibility (A11y) for Global Accessibility Awareness Day by utilizing some of your technical code optimization chops to help millions of disabled fellow humans have a better experience on the web.
Let’s be very clear though: learning web accessibility is no small task. This is a complex industry where assistive technologies go beyond just optimizing a bit of web code for screen readers.
But here’s where it’s simple for you to start: Some of the tasks of optimizing for web accessibility overlap with the things we look at for search engine optimization (SEO). At the most basic level, it’s important not to cannibalize the screen reader experience by over-optimizing for SEO by doing things like keyword stuffing. At a more advanced level, you’re top-notch if you can recognize the overlaps and consider how to optimize for both screen readers (AKA humans, in essence) and for search engines (bots).
In this post we’ll look at some simple structure overlaps. In next week’s post, we’ll dive more into overlaps in formatting and links, including what may be somewhat controversial: hidden text. And in the final post, we’ll look at accessibility and SEO overlaps optimizing video, images and non-text elements, including making infographics accessible.
SEO/A11y Overlaps: Structure
Markup on a page helps both search engines and assisitive technologies (AT) like screen readers to understand what elements are in a page. For SEO, different elements like title tags, headings, or some schema markup can have more weight or value than other markup. People using assistive technologies are reliant on these structural elements to navigate through the page without being able to see it or without being able to use a mouse.
We’ll start with some easy SEO + accessibility overlaps: structural elements that you might deal with in your every day coding or optimization. Consider the accessibility side of implementing and optimizing these elements to provide a better experience for disabled visitors while you also build for SEO.
Title tags (not to be confused with title attributes) are important in search engine optimization for (1) providing context as to what the page is about when Google crawls it and (2) how the page appears in the search result display. Over the years, while SEO techniques have come and gone and fluctuated in perceived effectiveness, page titles have continued to be one of the more highly valued on-page tactics.
When considering accessibility, W3C provides these specific benefits of the page title for various disabilities:
- This criterion benefits all users in allowing users to quickly and easily identify whether the information contained in the web page is relevant to their needs.
- People with visual disabilities will benefit from being able to differentiate content when multiple web pages are open.
- People with cognitive disabilities, limited short-term memory, and reading disabilities also benefit from the ability to identify content by its title.
- This criterion also benefits people with severe mobility impairments whose mode of operation relies on audio when navigating between Web pages.
Here’s a sample of the ChromeVox extension announcing the content of several tabs in a browser window by reading the title tags (and page focus).
Title tag do’s and don’ts
- Do continue to follow page title best practices for SEO. This should work hand-in-hand with titling for accessibility.
- Do not keyword stuff. In case keyword stuffing is still your thing, consider how something like this reads (“Buy Soap Dispensers, Pump Soap Dispensers, Sensor Soap Dispensers & more | MyStore”) versus “Soap Dispensers from MyStore.” Keep it simple and relevant (and split content into separate pages if you need to).
In search engine optimization, there’s a lot of focus on the H1 tag, and much less on nested H2–H6 headings. An H1 heading indicates the main topic of a page, while H2–H6 indicate subtopics or page sections. SEOs will sometimes use multiple H1 headings in an attempt to give more emphasis to more of the keywords and content on the page. SEOs will also sometimes tag other text on the page or in the footer as an H1 heading, in an attempt to get more keyword-rich H1 text in front of search engines. This can really mess with screen readers, and here’s why.
Headings allow assistive technologies to quickly navigate a page. Headings define the structure of the page and a screen reader user will oftentimes use these as the first method to move to a particular module or region of content.
Here’s an example of tabbing through headings using ChromeVox on the Santa Cruz Good Times news website:
Compare that to the Lehighton Times News, where only one heading was used, and it’s on the Calendar.
Heading do’s and don’ts
- Do use headings. It’s important not to skip headings altogether, like in the Times News website example above.
- Don’t use more than one H1 heading: HTML5 allows for multiple H1s, but this is not well-supported by browsers/assistive technology.
- Do use headings to define sections of content. For example, use H2 headings for subheader or key sections of the page and H3 headings for content modules.
- Don’t use headings if there’s no following content. Headings define sections of content, so if there is no content section, it shouldn’t have a header.
HTML5 elements and schema markup
HTML 5 introduced more detailed tagging of page elements, like <article>, <section>, <header>, <footer>, and a whole bunch more. Additionally, schema markup was developed by Google, Yahoo, and Bing to better understand elements of a page.
We know that Google uses some schema elements for rich snippets in search results, like review markup to get star ratings to appear in search results. What we don’t know is how many of the 571 schema types that the search engines pay attention to when indexing and forming context around a page and its elements, and/or what HTML 5 elements are considered and how they’re weighted.
Regardless, this tagging allows various assistive devices via different browsers to better understand and navigate through content. Check out these accessibility scores of HTML 5 elements via different browsers from html5accessibility.com. The page has a lot more interesting detail.
Semantic markup do’s and don’ts
- Do markup your content with relevant tags. It’s likely good for everyone.
- Do not use divs or spans for buttons. Div and span-based buttons are not accessible. If it looks and acts like a button, use a button.
Page structure & navigation
Some SEO camps might be zealous about putting the body copy or most important content of the source code at the very beginning of the source code, in an attempt to either make sure it’s indexed before Google leaves the page or to attempt to indicate that content is more important.
Whether you’re of that camp or not, it’s not a great idea for accessibility. The order of the source code content is important for being able to easily tab through content with your keyboard in the correct order. Ideally this looks something like: H1 heading, main navigation, site sections, and then footer. You can make modifications via the CSS, as long as your source code order is logical. It helps to have good semantic markup.
Page structure and navigation do’s and don’ts
- Do make sure your source code is in order. You can change things around via CSS, but a keyboard will tab through page content as it is listed in the source code.
This one is pretty straightforward. When search engines and screen readers are having trouble discerning the complex, convoluted, complicated navigation or otherwise hard-to-reach sections and pages of your website, a simple outlined sitemap with links to all the sections and pages can provide a quick and easy solution to fuller indexation and understanding the contents of a website.
Sitemap do’s and don’ts
- Do provide an on-site sitemap, if it’s possible. Link to all sections of the site, present the same organization as the site presents, and keep the links updated.
- Don’t keyword stuff. We’re all familiar with those sitemaps that repeat the site’s keyword in every link, like used cars alabama, used cars alaska, used cars arizona, used cars arkansas. You’re likely to drive a screen reader user to drink. Don’t do it.
Resources & tools
- Web Content Accessibility Guidelines (WCAG) 2.0 – W3C.org’s recommendations for making websites more accessible
- WebAIM Screen Reader Survey – Lots of interesting stats about what blind users use, how they navigate, sites they like and avoid, etc.
- WCAG Checklist
- WAVE Web Accessibility Evaluation Tool
- JAWS screen reader – the popular Windows screen reader
- Chrome screen reader extension ChromeVox
- Chrome Accessibility Developer Tools extension
for Accessibility and Structure:
- W3C Headings & Accessibility
- WebAIM Keyboard Accessibility
- W3C Making the DOM order match the visual order
- W3C Positioning content based on structural markup
- Getting started with schema.org using Microdata
- A great sitemap example: The Web Accessibility Sitemap
Next Week: SEO/A11y Overlaps: Formatting & Links
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!