G3ict is the Global Initiative for Inclusive ICTs

G3ict: The Global Initiative for Inclusive ICTs
Find Us: FacebookTwitterLinkedInFlickrRSS Share:
Search | Site Map | Contact
You're currently not logged in. Login | Register
Home  »  Resource Center  »  G3ict Newsletter  »  News
Guest Blogger

Subscribe to Newsletter
Tell a Friend
Print this Page


SEO and Accessibility Overlap: Accessibility is a Critical Component of Websites

Liam McGee serves as a W3C Invited Expert, actively developing international web standards and support materials as part of the organization’s Web Accessibility Initiative. Here he gives a comprehensive account of the connection between an accessible website and SEO.
I first became interested in SEO around five years ago, when I started to investigate the reason for the increased visits we saw whenever we improved the accessibility of a website. The main referrer of these extra visitors turned out to be Google. The skills we had developed in the field of web accessibility were, it seemed, directly applicable to many of the search engine optimisation (SEO) challenges that face search specialists every day.

We first started working in the field of SEO a year or so later due to our reputation as accessibility experts… a well-respected Google consultant had a knotty visibility problem, and he came to us for advice. Ever since, when Paul and I are not engaged in solving people’s accessibility problems, we are frequently to be found working for the Search:Johnston Google Consultancy, run by the estimable Steve Johnston, SEO guru of the ‘white hat’ variety (try Googling for ‘Google Consultant’). We work to improve the visibility of websites to Google, the relevancy of their content to the vocabulary used in search queries, and the reputation of their sites – both real and algorithmically determined – that make them rank better than other, less respected sources of information.

Google has a couple of things it wants to determine for each web page in its index (although my own specialism is Google, this all applies to Yahoo, Bing, Ask and the others.). Firstly, it has to be able to determine its relevance to a search query. To do this, it must be able to read the web page; it also has to understand what it is reading. It is in this area – making web content perceivable, and understandable – where the overlap with accessibility is most apparent. Secondly, it has to determine the reputation of the web page. This is a bit more complicated, and the overlap is more subtle (but important!), but we’ll come to that later. Let’s start with reading and understanding part.

Firstly: read it, understand it

If Googlebot can’t get to a page, it’s not going to be indexed. Simple as that. Even when it finds it, the more context a page author can give about the relative importance of different information on the page, the better. Google is blind. Google doesn’t use a mouse. Google sometimes has trouble with javascript. Like a blind person using screenreader software, Google relies on structural cues in the content – denoting headings, paragraphs, lists and more – to make more sense of the page.

(Please note that the ‘blind user using screen reader software’ is by no means the only kind of user with a disability who appreciates an accessible website. But quite a few of the accessibility guidelines are aimed at accessibility to screenreaders, and it is, by and large, where the overlap lies).

The accessibility guidelines relating to perceivability and operability are directly applicable to the problem of Google visibility. Google and screen-reader users want to know fairly similar things: Can you read it in the first place? Is it navigable? Are scripts or other complications getting in the way? Can you get to everything without needing a mouse? Without needing special tech such as scripts or embedded players? Are there headings, subheadings, titles, paragraphs? What are they? Do they tell you about the content of the page? Where is a word or phrase located in the text? Near the beginning? Near the end? Let’s have a look at a few WCAG 2.0 guidelines and success criteria in more detail.

Text text text text text

Google only sees text. It’s working on better ways of indexing images, video and audio, but it’s a long way off yet. If you are presenting non-text content, unless you provide text alternatives or transcripts, it’s never going to rank. You are exhorted to do this very thing by both WCAG 2.0, 1.1: Provide text alternatives for any non-text content and WCAG 2.0, 1.2: Provide alternatives for time-based media There’s also good old WCAG 2.0, 1.4.5: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text….

From Google’s point of view, using text instead of images thereof makes content easier to index. Neat use of alt attributes can mitigate this, but to be kind to Googlebot, keep to text (especially for headings!) wherever possible.

If you build it, they will come

HTML, used carefully, can give a lot of clues as to the relationships and relative importance of the text on a page, using structures such as Titles, Divs, Headings, Paragraphs and Lists – to name but a few. The better structured your mark-up, the easier it is for Googlebot to understand. Google wants to know what the important sections of a page are, and what topics each covers. Providing this information is just what you need to do to pass WCAG 2.0, 1.3.1: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text; WCAG 2.4.6: Headings and labels describe topic or purpose; and WCAG2.0 2.4.10: Section headings are used to organize the content.

We don’ need no steenkin’ mice

If you can’t reach it with your keyboard, chances are Google can’t either. In fact, Google’s advice to webmasters often suggests using Lynx (a text-only browser) to check how your site might appear to Googlebot. You would be amazed how often sites – especially big ones – mess this up. Javascript-only links are the typical culprit. If you follow the guideline laid out in WCAG 2.0, 2.1: Make all functionality available from a keyboard, you won’t go far wrong.

What the heck just happened?

Do not autorefresh. Top SEO tip. Happily, this won’t be a problem if you stick to WCAG2.0, 2.2: Provide users enough time to read and use content. Ensure that important content is not time-dependent. Do not autorefresh.

Navigation’s what you need

Key vocabulary in navigation labels, along with structural relationships (nested lists can be used for menu structure, for example), is a great help to Googlebot. Following the advice in WCAG 2.0, 2.4: Provide ways to help users navigate, find content, and determine where they are will get you a fair way down the road to Google-friendly navigation.

What’s in a name?

Titles are probably the single most important piece of text relating to a page. SEO books devote whole chapters to how best to construct them. They are important for screenreaders users too – it’s the first piece of text you arrive at. The W3C resources to support WCAG 2.0 2.4.2: Web pages have titles that describe topic or purpose include a reference to ‘Writing Better Web Page Titles How to write titles for Web pages that will enhance search engine effectiveness’.

More meat

Googlebot’s appetite is limited, so SEO guidance ususally emphasises the importance of aiming for maximum content, minimum cruft. Hone mark-up for simplicity. Separate layout, styling and scripts into an external file wherever reasonable to do so. This is less important, accessibility-wise, than it used to be, but keeping those file-sizes low is good for everyone, especially those on slow connections (mobile phone users, anyone?).

Secondly: rate it, rank it

WCAG 2.0, 2.4.9: The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
How does Google determine the reputation of each web page in its index? It does it using what I like to think of as Google’s Big Bag of Love.

(This is my own twist on the elegant explanation laid out in “PageRank and Beyond”, by Amy Langville and Carl Meyer. My version uses more metaphor and less matrix maths).

To begin, Google shares out all the love from its bag between all the pages it has found on the web. The amount of love received by each page in this initial love-share might depend on the form and length of anchor text pointing to the page, the location of links to the page in the pages pointing to it, and the similarity of the content between linkers and linkees. (Another powerful way of refining the initial shares would be to know where real people go on web pages… and adjust the shares depending on the shares of visitors. This may be why Google Analytics is both free and rather good). Then Google blows a big Google whistle (in my head, anyway), and every page gives all the love it has to all the pages it links out to, and then turns to receive love from all the pages that link in to it.

Google, if it’s still doing it like Amy and Carl suggest, gets around 15 in every hundred pages a bit drunk, a bit giggly, so they run around joyfully handing out their love to complete stranger pages (in what are, I suppose, random acts of love), rather than to those they link to. This probably isn’t a great way of sustaining your own relationships at parties, but in Googleworld it stops love piling up with pages who do not pass it along; it keeps things interesting, and ensures elegance. Google will blow its big Google whistle a fair few times, each time watching all the pages run around, passing love out, and receiving it in. Google gets bored after around 142 (specific, no?) blasts of the big Google whistle. By this time, all the pages have calmed down a bit, and each new step in the crazy love-sharing, they seem to end up with pretty much the same amount of love in their bag as they began the step with. The love held by each page is recorded in, well, I suppose it would be the list of love.

So how does all this relate to accessibility? One of the key ways a screenreader user navigates a website is by listing the links on the page. They are listed out of context – just the link text. It’s an extremely effective way of moving through a site – experienced screenreader users can be faster at using the web than a mundane sighted user! But it only works if the phrases in the link text make sense when read on their own. So, best practice for accessible web pages is that the text of a link (the bit that gets underlined or highlighted) should make sense when read out on its own – the purpose of the link should be apparent. ‘Click here’ is no good – you have no idea what clicking there might do. This is just perfect for Google. When Google is making its decisions about the form or content of anchor text pointing to the page, anchors with useful, relevant text are going to result in better performance of that page in the, uh, love-sharing (I’m beginning to regret this metaphor).

What does Google say?

You don’t have to take my word for all this. I’m going to leave you with a few quotes from the good folks at Google about the benefits of accessible pages (I would have happily included quotes from the equivalent folks at Yahoo, Bing or Ask/Teoma, but I couldn’t find anything as good, apart from some general advice to use well formed HTML).

Why should you take the time to make your site more accessible? In addition to the service you’ll be doing for the visually-impaired community, accessible sites are more easily crawled, which is a first step in your site’s ability to appear in search results.
T.V. Raman, Google Research Scientist, Official Google Webmaster Central Blog

Consider accessibility. Not all users may have JavaScript enabled in their browsers. In addition, technologies such as Flash and ActiveX may not render well (or at all) in every browser. We recommend following our guidelines for using Flash and other rich media, and testing your site in a text-only browser such as Lynx. As a bonus, providing text-only alternatives to rich-media content and functionality will make it easier for search engines to crawl and index your site, and also make your site more accessible to users who use alternative technologies such as screenreaders.
Browser compatibility, Google Webmasters/Site Owners Help Pages

Images: Use the alt attribute to provide descriptive text. In addition, we recommend using a human-readable caption and descriptive text around the image. Javascript: Place the same content from the Javascript in a no script tag. If you use this method, ensure the contents are exactly same as what is contained in the Javascript and that this content is shown to visitors who do not have Javascript enabled in their browser. Videos: Include descriptive text about the video in HTML. You might also consider providing transcripts.
Hidden text and links, Google Webmasters/Site Owners Help Pages

[On javascript reliance] …When you’re designing your AJAX site, think about the needs of your users, including those who may not be using a JavaScript-capable browser (for example, people who use screen readers or mobile devices). One of the easiest ways to test your site’s accessibility is to preview it in your browser with JavaScript turned off, or to view it in a text-only browser such as Lynx. Viewing a site as text-only can also help you identify other content which may be hard for Googlebot to see… [On iFrames] …Avoid iFrames – or link to their content separately…” [On progressive enhancement] …If you’re starting from scratch, a good approach is to build your site’s structure and navigation using only HTML. Then, once you have the site’s pages, links, and content in place, you can spice up the appearance and interface with AJAX. Googlebot will be happy looking at the HTML, while users with modern browsers can enjoy your AJAX bonuses…When creating your links, format them so they’ll offer a static link as well as calling a JavaScript function. That way you’ll have the AJAX functionality for JavaScript users, while non-JavaScript users can ignore the script and follow the link… using HTML links remains a strong way to help us (as well as other search engines, mobile devices and users) better understand your site’s structure.
Liam has been involved in the fields of web standards, mark-up and accessibility since 1995. He is actively involved in accessibility research – typography, information architecture and web interface design – and is a respected contributor to industry groups. 


Related Items:

• GameON

• Accessibility Online: A Neglected Frontier for People with Disabilities

• Nominations Open for U.S. FCC Chairman’s Award for Advancement in Accessibility (AAA)

• Accessibility Summit 2014: Web and Mobile Accessibility, Online Event

No records were found.
Post new comment:
Only register users can add comments please Log-in