Can Better Web Accessibility Mean Better Search Ranking?

As I write this, Google Labs is developing their Web Accessible Search Engine which gives a higher priority in search results to pages which meet the W3C WAI Web Content Accessibility Guidelines (WCAG).

Similarly, Net-Guide - a UK-based search engine - excludes non-compliant web sites in favor (or maybe that should be favour) of Web Accessible ones.

Rollyo's Teaching In My PJs Search Engine specifically targets web accessible sites. This short list of Web Accessible-Friendly Search Engines will no doubt be expanding in the future.

Why? In theory, a website owner that fails to provide accessible information and functionality for all users could be sued for discriminating against disabled people. Could your company survive a costly discrimination law suit?

If all that isn't sufficient reason for building web accessible sites then you're missing the upside. One of the main benefits of Web Accessibility is that a Website that's more accessible to people - all people - is also usually more accessible to search engines. That's right. And the more accessible your site is to search engines, the easier it is to identify your content for what it is. Better content identification provides a better chance at a top spot in search engine rankings.

To be honest, not all of the WCAGs will necessarily help you improve your search engine rankings. But there are many overlapping areas that could. So let's examine the important ones.

1. Descriptive Page Title

When we arrive at Web pages, the first thing that appears -- the first thing that visually impaired users hear -- is the page title. Visually impaired Web users don't have the privilege of being able to quickly scan the page to see if it contains the information they're after, so it's essential that the page title describes the page content in a meaningful way. "Home Page" or "Index" doesn't say much about the content contained on your opening page. Whereas "Your Company Name - Start Page" says more.

If you know anything about search engine optimization you'll know that the page title is among the most important attributes on the page. If it adequately describes the content of that page, more search engines will be able to accurately interpret what that page is about.

2. Use Headings and Sub-Headings

Visually impaired web users can scan web pages by tabbing from heading to heading, as well as from link to link (see point 3 below). As such, it's important from an accessibility standpoint to make sure your headings are correctly marked up using <h1>, <h2>, etc. tags.

As a general rule, most search engines will assume that the text contained in heading tags is more important than the rest of the document's text, as headings describe the content immediately below them. Search engines assign the greatest importance to <h1>, then <h2>, and so on. Make sure you use the heading tags properly. Don't abuse them -- the more text you have contained between heading tags, for example, the less importance search engines may assign them.

3. Use Descriptive Link Text

Visually impaired Web users can scan Web pages by tabbing from link to link, listening to the content of the link text as they go. As such, the link text in an accessible Website must always be descriptive of its destination.

Search engines are generally seen to place importance on link text, too. Many engines assume that link text will be descriptive of its destination, so they examine the text of all the links that point to a given page. For instance, if all the links pointing to a page about widgets read, 'click here', search engines can't gain any information about that page without visiting it. If, on the other hand, all the links say, 'widgets' then search engines can easily guess what the linked page is about.

One of the best examples of this technique in action is for the search term, 'miserable failure'. So many people have linked to George Bush's bio using this phrase as the link text, that now when the words "miserable failure" are searched on Google, George Bush's bio appears on top of the search rankings!

4. Assign ALT Descriptions to Images

Screen readers, which are used by many visually impaired Web users, can't understand images. To ensure accessibility, an alternative description needs to be assigned to every image; the screen reader will read out this alternative, or ALT="image description goes here."

Like screen readers, search engines are commonly assumed to be unable to understand images. But some search engines index ALT text. By assigning ALT text to your images, those engines will be able to understand even your pictorial content.

Of course, numerous search engines don't take any notice of ALT text. The proliferation of ALT tag spamming undermined the relevance of ALT text in the eyes of these engines, which no longer consider it in their relevance algorithms.

So, why bother with image ALT text? Because your rankings may improve in search engines that do take it into account, and make your site more accessible.

5. Display Text Through HTML or XHTML, Not Images

Text embedded in images appears pixelated, blurry, and is often unreadable by those who use screen magnifiers. From an accessibility point of view, text embedded in images should therefore be avoided.

It seems that at present, search engines are also unable to read text embedded in images. Well, you can just apply ALT text to those images, right? Unfortunately, there's strong evidence to suggest that search engines assign less importance to ALT text than they do to regular text. Why? Spammers (again!), as explained above.

The answer? To ensure that your site is accessible and your content counts as much as possible toward your search ranking, avoid embedding text in images.

6. Disabled Website Functions

JavaScript is unsupported by about 4% of Web users, either because they've turned it off for security reasons (perhaps to prevent pop-up ads) or because their browser may not support it. Many forms of JavaScript - Dynamic link menus, AJAX, Sprys, etc... may not be accessible to those who use screen readers.

It's accepted that few, if any, search engines can understand JavaScript - see Getting Into Google - Google Speaks. These services will likely be unable to index any JavaScript-driven content. Perhaps more importantly, they'll also be unable to follow JavaScript-driven links. You may really like the look of your dynamic or Flash-driven drop-down menus, but search engines won't if they can't access pages on your site via regular text links.

7. Provide Alternative Text for Flash and Java based Content

Flash and Java aren't accessible to many users either, including those using screen readers. Likewise, few search engines can access Flash or Java so be sure to provide HTML or XHTML equivalents.

8. Transcripts Available for Audio

Hearing impaired users obviously require written equivalents for audio content in order to access that information. Typically, search engines are also unable to access audio content whereas 'transcripts' provide relevant text that can be indexed by Search Engines.

9. Provide a Site Map

Site maps can be a useful tool for visually impaired users as they provide a straightforward list of links to the main pages on the site.

Site maps are also great for search engines because most search engines can instantly index your entire site once they arrive at the site map. Next to each link you might also provide a short keyword-rich preview of the page, to improve both the user experience and potential search ranking. This is particularly important for dynamically driven web sites whose content is contained in a database. All links should, of course, be made through regular HTML or XHTML expression and not JavaScript, AJAX, Flash or Java (see points 6 & 7 above).

10. CSS Used for Layout

Screen readers can more effectively work through the XHTML or HTML code of CSS-based sites as there's a greater ratio of content to code. Websites using CSS-based layouts can also be made accessible for specific devices such as computer printers, handhelds (Mobile Phones, Blackberries), braille printers, aural readers, TV and others.

Search engines tend to rate CSS-based sites higher in search rankings because:

• The code is cleaner and therefore more accessible to search engines
• Important content can be placed at the top of the HTML document
• There is a greater density of content compared to coding

Several web site designers have told me that when they changed their site from regular table-based layouts to a CSS-based layout, traffic stats to their sites increased significantly.

Summary

With the overlap between improved Web Accessibility and Search Engine Optimization (SEO) there's no reason NOT to incorporate basic web accessibility methods into your websites. It's a bit like the Mother Goose rhyme, The House That Jack Built... Build a Web Accessible site to improve your site's perception and visibility by search engines. Greater visibility by search engines might lead to higher search rankings. Higher search rankings could lead to more site visitors. More site visitors means more potential customers. And so on...

References:

• Accessible-Search
• Accessible-Search-Friendly-Sites
• Web Accessibility Tools
• Getting Into Google - Google Speaks
• Google Web Accessible Search Engine
• Global User Stats - July 2007
• Rollyo's Web Accessible Search Engine
• WCAG 2.0

Getting Into Google

Excerpted article by Jill Whalen - High Rankings Advisor - Search Engine Optimization Newsletter

If you don't already know about this SEO newsletter, you might want to have a closer look. Lots of good information on what you can do to improve your web site's search engine rankings.

Google Speaks

Last night was our third SEMNE event (Search Engine Marketing New England), and we were humbled to have Dan Crow, director of crawl systems at Google, spilling the beans about how to get your site into Google.

What is Indexing?

Dan started out his presentation discussing what “indexing” means and how Google goes about it. Basically, the process for the Google crawler is to first look at the robots.txt file in order to learn where it shouldn’t go, and then it gets down to business visiting the pages it is allowed to visit. As the crawler lands on a page, it finds the relevant information contained on it, then follows each link and repeats the process.

Robot Txt Explored

Dan proceeded to explain how to use your robots.txt file for excluding pages and directories from your site that you might not want indexed, such as the cgi-bin folder. He told us how each of the major search engines have their own commands for this file but that they’re working to standardize things a bit more in the future. In terms of what the crawler looks at on the page, he said there are over 200 factors, with “relevance” playing a big part in many of them.

Google still loves it's Page Rank

Dan also discussed the importance of PageRank (the real one that only Google knows about, not the “for-amusement-purposes-only” PageRank Toolbar that many obsess over). He let us know that having high-quality links is still one of the greatest factors towards being indexed and ranked, and then he proceeded to explain how building your site with unique content for your users is one of the best approaches to take. (Now, where have you heard that before?) He explained how creating a community of like-minded individuals that builds up its popularity over time is a perfect way to enhance your site.

Did You Know About These Tags?

We were also treated to some additional tips that many people may not have known about. For instance, did you know that you could stop Google from showing any snippet of your page in the search engine results by using a “nosnippet” tag? And you can also stop Google from showing a cached version of your page via the “noarchive” tag. Dan doesn’t recommend these for most pages since snippets are extremely helpful to visitors, as is showing the cache. However, Google understands that there are certain circumstances where you may want to turn those off.

Breaking News!

Google is coming out with a new tag called “unavailable_after” which will allow people to tell Google when a particular page will no longer be available for crawling. For instance, if you have a special offer on your site that expires on a particular date, you might want to use the unavailable_after tag to let Google know when to stop indexing it. Or perhaps you write articles that are free for a particular amount of time, but then get moved to a paid-subscription area of your site. Unavailable_after is the tag for you! Pretty neat stuff!

Webmaster Central Tools

Dan couldn’t say enough good things about their Webmaster Central Tools. I have to say that seems to be very common with all the Google reps I’ve heard speak at various conferences. The great thing is that they’re not kidding! If you haven’t tried the webmaster tools yet, you really should because they provide you with a ton of information about your site such as backward links, the keyword phrases with which people have found each page of your site, and much, much more!

Sitemaps Explored

One of the main tools in Webmaster Central is the ability to provide Google with an XML sitemap. Dan told us that a Google sitemap can be used to provide them with URLs that they would otherwise not be able to find because they weren’t linked to from anywhere else. He used the term “walled garden” to describe a set of pages that are linked only to each other but not linked from anywhere else. He said that you could simply submit one of the URLs via your sitemap, and then they’d crawl the rest. He also talked about how sitemaps were good for getting pages indexed that could be reached only via webforms. He did admit later that even though those pages would be likely to be indexed via the sitemap, at this time they would still most likely be considered low quality since they wouldn’t have any PageRank. Google is working on a way to change this in the future, however.

Flash and AJAX

Lastly, Dan mentioned that Google still isn’t doing a great job of indexing content that is contained within Flash and/or AJAX. He said that you should definitely limit your use of these technologies for content that you want indexed. He provided a bit of information regarding Scalable Inman Flash Replacement (sIFR), and explained that when used in the manner for which it was intended, it’s a perfectly acceptable solution for Google. Dan said that Google does hope to do a better job of indexing the information contained in Flash at some point in the future.

The Q&A

Many of the points mentioned above were also covered in greater detail during Dan’s extensive Q&A session. However, there were many additional enlightening tidbits that got covered. For instance, Sherwood Stranieri from Catalyst Online asked about Google’s new Universal Search, specifically as it applied to when particular videos (that were not served up from any Google properties) would show up in the main search results. Dan explained that in Universal Search, the videos that show up are the same that show up first while using Google’s video search function.

The Dreaded Supplemental Results

Of course, someone just *had* to ask about supplemental results and what causes pages to be banished there. (This is one of the most common questions that I hear at all SEO/SEM conferences.) Dan provided us with some insights as to what the supplemental results were and how you could get your URLs out of them. He explained that basically the supplemental index is where they put pages that have low PageRank (the real kind) or ones that don’t change very often. These pages generally don’t show up in the search results unless there are not enough relevant pages in the main results to show. He had some good news to report: Google is starting to crawl the supplemental index more often, and soon the distinction between the main index and the supplemental index will be blurring. For now, to get your URLs back into the main results, he suggested more incoming links (of course!).

References:

• Subscribe to High Rankings Advisor
• Google Webmaster Central Tools

Usability of Websites for Teenagers

Excerpted from an article by: Jakob Nielsen

Sumary:

When using websites, teenagers have a lower success rate than adults and they're also easily bored. To work for teens, websites must be simple - but not childish - and supply plenty of interactive features.

It's almost cliché to say that teenagers live a wired lifestyle, but they do. Teens in this study reported using the Internet for:

• School assignments
  
• Hobbies or other special interests
  
• Entertainment (including music and games)
  
• News
  
• Learning about health issues that they're too embarrassed to talk about
  
• E-commerce
  

And, even when they don't make actual purchases online, teens use websites to do product research and to build gift wish-lists for the credit-card carrying adults in their lives.


Misconceptions about Teens

Many people think teens are techno-wizards who surf the Web with abandon. It's also commonly assumed that the best way to appeal to teens is to load up on heavy, glitzy,
blinking graphics.

Our study refuted these stereotypes. Teenagers are not in fact superior Web geniuses who can use anything a site throws at them. We measured a success rate of only 55 percent
for the teenage users in this study, which is substantially lower than the 66 percent success rate we found for adult users. (The success rate indicates the proportion of times users were able to complete a representative and perfectly feasible task on the target site. Thus,
anything less than 100 percent represents a design failure and lost
business for the site.)

Poor Teen Performance cause by three things:

• insufficient reading skills,


• less sophisticated research strategies,


• dramatically lower patience level.

What do teens like?

Cool-looking graphics and they pay more attention to a website's visual appearance than adult users do.

The sites that our teen users rated the highest for subjective satisfaction were sites with a relatively modest, clean design. They typically marked down overly glitzy sites as too difficult to use. Teenagers like to do stuff on the Web, and dislike sites that are slow or that look fancy but behave clumsily.

No Boring Sites

Teens frequently complained about sites that they found boring. Being boring is the kiss of death in terms of keeping teens on your site. That's one stereotype our study confirmed: teens have a short attention span and want to be stimulated. That's also why they leave sites that
are difficult to figure out.

Teens don't like to read a lot on the web

They get enough of that at school. Also, the reading skills of many teenagers are not what one might hope for, especially among younger teens. Sites that were easy to scan or that illustrated concepts visually were strongly preferred to sites with dense text.

Teens don't like tiny font sizes

We have always assumed that tiny text is predominant on the Web because most Web designers are young and still have perfect vision, so we didn't expect to find issues with font sizes when testing even younger users.

However, small type often caused problems or provoked negative comments from the teen users in our study. Even though most teens are sufficiently sharp-eyed, they move too quickly and are too easily distracted to attend to small text.

What's good?

The following interactive features all worked well because they let teens do things rather than simply sit and read:

• Online quizzes
  
• Forms for providing feedback or asking questions
  
• Online voting
  
• Games
  
• Features for sharing pictures or stories
  
• Message boards
  
• Forums for offering and receiving advice
  
• Features for creating a website or otherwise adding content
  

These interactive features allow teenagers to make their mark on the Internet and express themselves in various ways -- some small, some big.

Differences between age groups

Some websites in our study tried to serve both children and teens in a single area, usually titled something like Kids. This is a grave mistake; the word "kid" is a teen repellent. Teenagers are fiercely proud of their newly won status and they don't want overly childish content (one more reason to ease up on the heavy animations and gory color schemes that actually work for younger audiences). We recommend having separate sections for young children

and teens, labeling them Kids and Teens, respectively.

---

References:

• Nielsen Norman Group Report: Teenagers on the Web: 61 Usability Guidelines for Creating Compelling Websites for Teens - 130 page PDF report.
• Excerpted from an Article by: Jakob Nielsen

---

Mobile Web Design

In light of the World Wide Web Consortium's (W3C's) "One Web" view, it seems to me that the Mobile Web era is forcing many web designers to build better web sites. From a practical standpoint, if you have a well-designed desktop site, your foray into building a good mobile web site should be a fairly straightforward process. If, however, your desktop site favors table-based layouts, bloated code, frames, and image based navigation, then I'm afraid your first mobile web site will be a whole new experience - which is probably a very good thing.

Dropping Dynamic Effects

Opera for handhelds supports the same dynamic effects as Opera for the desktop. However, a lot of dynamic effects that work well for the screen just do not adapt well to the handheld. Features that are a bit annoying on the desktop become even more annoying on handhelds.

Don’t use frames or pop-up windows. Although Opera can display frames on handhelds, they make navigation and display painfully awkward. Multiple windows are also far more unwieldy on a handheld than on a desktop, so keep all links going to the same window.

As with desktop layouts, make sure navigational elements are accessible even without the mouse. Keyboard events don’t necessarily apply, either; interaction on handhelds is often only with a stylus, which does not track keypress or hover events and cannot right-click or double-click.

Reducing the Images

Mobile phone operators delight in charging per kilobyte of transfer, making image-intensive sites both slow and expensive to download. This often causes users to browse with images turned off to save time and money.

You can make your design less image-intensive by:

• Hiding unnecessary images with display: none so that Opera will not bother to download them.
• Using real text for navigation labels and headers.
• Telling Opera to use an image’s alt text instead of loading the image itself:

  img.as-text { content: attr(alt); }

For the images you do include, set the width and height attributes so that the page can be laid out in its final form even before the images are loaded. Also, images designed for the desktop often do not scale well to the small screen. Crop, scale down, and/or size-optimize images targetted at handhelds.

Don’t forget to write meaningful alternative text. The idea is to replace the image, not to describe it. If the image is purely ornamental, the alt text should always be the empty string ("").

Optimizing HTML

Use efficient, semantic markup and leave the presentation to CSS. CSS is more powerful, more compact, and does not clutter the document with redundant presentational data. Although this is good authoring practice for all media types, it does become even more important when authoring for handheld devices.

• Don’t overdose on class,
  and . If there is a more appropriate HTML tag, use that and subclass if necessary. If the element is not actually necessary, take it out. If you can select based on context, do not introduce another class.
• Choose the tags that best convey the purpose and structure of the content. Semantic HTML tags have universally-recognized meanings, which font changes and author-defined classes don’t. Among other advantages, meaningful markup allows non-CSS browsers, which are more common on small devices than on the desktop, to present the reader with a coherent display of the page content. Semantic tags are also a lot shorter than div+class combinations, leading to smaller file sizes.

Reference: http://alistapart.com/articles/pocket/

---

How does your web site perform on mobile phones?

On-Line Mobile Phone Emulators:

• DotMobi


• http://www.operamini.com/demo/

OnLine Mobile Site Checkers

MobileOK test schemes are based on the W3C Mobile Web Best Practices List shown below.

• http://ready.mobi - on-line mobile site checker


• http://validator.w3.org/mobile/

---

The W3C Mobile Web Best Practices 1.0 Guidelines

1. [THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.


2. [CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.


3. [DEFICIENCIES] Take reasonable steps to work around deficient implementations.


4. [TESTING] Carry out testing on actual devices as well as emulators.


5. [URIS] Keep the URIs of site entry points short.


6. [NAVBAR] Provide only minimal navigation at the top of the page.


7. [BALANCE] Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.


8. [NAVIGATION] Provide consistent navigation mechanisms.


9. [ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality.


10. [LINK_TARGET_ID] Clearly identify the target of each link.


11. [LINK_TARGET_FORMAT] Note the target file's format unless you know the device supports it.


12. [IMAGE_MAPS] Do not use image maps unless you know the device supports them effectively.


13. [POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.


14. [AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.


15. [REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.


16. [EXTERNAL_RESOURCES] Keep the number of externally linked resources to a minimum.


17. [SUITABLE] Ensure that content is suitable for use in a mobile context.


18. [CLARITY] Use clear and simple language.


19. [LIMITED] Limit content to what the user has requested.


20. [PAGE_SIZE_USABLE] Divide pages into usable but limited size portions.


21. [PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to the memory limitations of the device.


22. [SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.


23. [CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.


24. [GRAPHICS_FOR_SPACING] Do not use graphics for spacing.


25. [LARGE_GRAPHICS] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.


26. [USE_OF_COLOR] Ensure that information conveyed with color is also available without color.


27. [COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast.


28. [BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device.


29. [PAGE_TITLE] Provide a short but descriptive page title.


30. [NO_FRAMES] Do not use frames.


31. [STRUCTURE] Use features of the markup language to indicate logical document structure.


32. [TABLES_SUPPORT] Do not use tables unless the device is known to support them.


33. [TABLES_NESTED] Do not use nested tables.


34. [TABLES_LAYOUT] Do not use tables for layout.


35. [TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.


36. [NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element.


37. [OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script.


38. [IMAGES_SPECIFY_SIZE] Specify the size of images in markup, if they have an intrinsic size.


39. [IMAGES_RESIZING] Resize images at the server, if they have an intrinsic size.


40. [VALID_MARKUP] Create documents that validate to published formal grammars.


41. [MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.


42. [STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.


43. [STYLE_SHEETS_SUPPORT] Organize documents so that if necessary they may be read without style sheets.


44. [STYLE_SHEETS_SIZE] Keep style sheets small.


45. [MINIMIZE] Use terse, efficient markup.


46. [CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device.


47. [CONTENT_FORMAT_PREFERRED] Where possible, send content in a preferred format.


48. [CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the target device.


49. [CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used.


50. [ERROR_MESSAGES] Provide informative error messages and a means of navigating away from an error message back to useful information.


51. [COOKIES] Do not rely on cookies being available.


52. [CACHING] Provide caching information in HTTP responses.


53. [FONTS] Do not rely on support of font related styling.


54. [MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum.


55. [AVOID_FREE_TEXT] Avoid free text entry where possible.


56. [PROVIDE_DEFAULTS] Provide pre-selected default values where possible.


57. [DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the target device is known to support it.


58. [TAB_ORDER] Create a logical order through links, form controls and objects.


59. [CONTROL_LABELLING] Label all form controls appropriately and explicitly associate labels with form controls.


60. [CONTROL_POSITION] Position labels so they lay out properly in relation to the form controls they refer to.

Reference: http://www.w3.org/TR/mobile-bp/