Accessibility is an important facet of the user experience and of one of its subsets, the searcher experience.
Too often, Web professionals put users and technology into silos. Usability and UX professionals view accessibility from a human/user perspective. And technical search engine optimization (SEO) professionals view accessibility purely from a technology perspective.
For example, Wikipedia’s definition of Web accessibility takes on the human perspective:
Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, all users have equal access to information and functionality.
In my opinion, website accessibility means creating an online environment in which all users, not only those with disabilities, are able to easily navigate, interact with and understand your website content.
In his initial User Experience Honeycomb, information architecture guru Peter Morville tended to emphasize people:
Just as our buildings have elevators and ramps, our websites should be accessible to people with disabilities (more than 10% of the population).
Six years later, Morville acknowledged the importance of both the human user and the technology user in his book, “Search Patterns”:
Will it work for all users? Are features and results accessible to blind and visually impaired users? Can people search from a wide variety of platforms and browsers?
Remember, people locate and discover desirable content via browsing, searching and asking. Findability is just as important as usability and accessibility in the user experience.
SEO professionals tend to focus on (a) the search part of findability and (b) technical accessibility. SEO professionals try to give the commercial Web search engines access to desirable content.
On the flip side, they also try to limit or prevent search-engine access to undesirable content (such as duplicates, password-protected documents and so forth).
Therefore, when measuring accessibility in the user experience, we should consider both humans and technology. Let me explain how I measure accessibility.
User (Human) Accessibility
In my opinion, website accessibility means creating an online environment in which all users, not only those with disabilities, are able to understand, interact with and easily navigate your website content.
In other words, accessibility does not only apply to people. Accessibility also applies to technology-based users, such as search engines.
I believe that website content should be written and formatted primarily for human users. However, since people use technology to access content, I also believe that website content should accommodate search engines.
Humans first. Search engines second.
Below is a list, written by Jared Smith from the WebAIM blog, of SEO and accessibility practices that are in alignment:
Using proper alternative text for images
Providing a clear and proper heading structure and avoiding empty headings
Providing descriptive link text (i.e., avoiding “click here”)
Ensuring page titles are descriptive, yet succinct
Not relying on JavaScript for things that don’t need it
Avoiding mouse-dependent interaction
Using standard Web formats when possible
Providing transcripts and captions for video
Identifying the language of pages and page content
Allowing multiple ways of finding content
Using text instead of images when possible
Providing useful links to related and relevant resources
Ensuring URLs are human readable and logical
Presenting a clear and consistent navigation and page structure
Avoiding CSS and other stylistic markup to present content or meaning
Defining abbreviations and acronyms
I use checklists to measure human accessibility. Since I am US-based, I use the Section 508 Checklist.
Since I am concerned with readability and scannability, I also use my Scannability Checklist when formatting content for desktop computers, tablets and mobile devices.
Feedback from actual users on multiple devices confirms whether or not content is scannable. A checklist is a good starting point.
Performance tests (both summative and formative) can help confirm whether or not content is truly scannable and readable.
When I test mobile websites, I might conduct the test in an outdoor environment, depending on the target audience. If I observe users covering the screen from the glare of the sunlight, then I know that color contrast might be an issue.
Two color-contrast checkers I use are the WCAG Contrast Checker for Firefox and the Color Contrast Checker from WebAIM. And if you need supporting documentation about low color contrast, please see Nielsen Norman Group’s Low-Contrast Text is Not the Answer.
Technical Accessibility
As I mentioned previously, SEO professionals try to provide easy access to desirable content and limited or no access to undesirable content. Sometimes, though, well-meaning SEO professionals limit access to desirable content.
Some ways they might accidentally do this are:
Robots.txt file.
Robots exclusion meta-tag. In an effort to minimize duplicate content, some search engine optimizers might not implement the robots exclusion meta-tag properly. Double-check this meta-tag to see if it is used properly.
Orphaning. Some content, such as content in a pop-up window, might not belong in a pop-up window. For example, I’ve seen a glossary (terms and definitions) formatted to only appear in a pop-up window, even though this content is certainly a linkworthy digital asset.
Siloing. Contrary to popular SEO opinion, siloing typically makes content more difficult to find. A network taxonomy might be a better choice than a hierarchical taxonomy.
JavaScript, AJAX, Flash and other Web technologies. One way I test JavaScript accessibility is turning it off in a browser. If the browser cannot access the text or links within the JavaScript, then it is likely that search engines cannot access that content.
URL structure. Use the URL Accessibility Checklist below to determine if your URLs are both technology-friendly and user-friendly.
URL Accessibility Checklist
As a search engine optimizer, I certainly understand the importance of keywords and entities.
1. Is the URL structure easy to type and easy to remember?
URLs should be short but descriptive. Users should understand what information a URL might contain.
One good way to test this is a usability test called an Expectancy Test. For this test, show test participants a URL and ask them what content they expect to see on this Web address. Show them URLs for text-based documents (including PDFs), as well as non-text based documents (e.g., images or video).
Remember, in an Expectancy Test, don’t show test participants the actual content. Participants commonly state afterward that they did expect to see something.
2. Do URLs contain important, relevant keywords?
URLs should reinforce content. Links and file names that begin with the most important words help users understand them more easily. Beginning a heading, title or file name with an important keyword is called frontloading.
Word order is also important for scannability and readability. Place words in the natural order that people use in a specific language. Be mindful of different dialects, as well, such as US-English, UK-English, Canadian-English.
3. Do URLs make sense to human users?
Minimize the use of jargon and unfamiliar abbreviations/acronyms in a URL structure. If the number of characters in a URL is an issue, it’s okay to use an abbreviation. Just make sure that you spell out the meaning of the abbreviation in content and the meta-tag description.
4. Do URLs contain few or no “funky” characters?
Even though search engines can crawl URLs with &, ?, =, %, + in them, it’s still best to minimize their usage whenever possible. In geek-speak, this means to minimize the number of dynamic parameters in a URL.
For a good explanation, read “(Please) Stop Using Unsafe Characters in URLs.”
5. Is the URL structure all lowercase?
This includes URLs to graphic images, multimedia and other text documents (such as PDFs). Though search engines can read and interpret URLs with mixed cases, websites hosted on Linux/Unix servers often interpret lowercase, mixed case and uppercase files as different documents.
6. Does the URL use hyphens, not underscores, as word separators?
Even though search engines can follow URLs with underscores in them, the readability of a URL link is slightly compromised.
For example (Note: The links below aren’t functional.):
www.domain.com/design-services is better than
www.domain.com/design_services
In the second URL, the underscore is difficult to see. On some browsers and devices, users cannot discern the underscore.
7. Do URLs have minimal use of stop words?
Minimizing or removing stop words (and, the, a, an, of, but, nor, for, etc.) shortens a URL. However, I don’t recommend removing stop words if removing them negatively affects the meaning of the URL.
8. Is the URL structure formatted to have no trailing forward slash?
Some content management systems add a forward slash to the end of a URL:
www.domain.com/services/
www.domain.com/services
I always check to see if both URLs load the same content in a browser. If both URLs present the same content, I use canonicalization so that search engines (and searchers) are not delivering duplicate content.
Canonicalization is the process of picking the best URL when there are several choices. See “8 Canonicalization Best Practices in Plain English.”
9. Are Web documents in the proper file format?
Some documents are best formatted in (X)HTML. Some documents are best formatted as PDF. Some images are better formatted as JPG. For an explanation of the different file types, please see “What’s the Difference Between JPG, PNG, and GIF?”
10. Do URLs look or seem spammy?
Don’t overdo keywords in URLs purely for search engine rankings. To measure, I use the Expectancy Test to determine the “spamminess” of URLs. If a considerable number of test participants mention that a URL looks odd or keyword-stuffed or spammy, make note of it.
Site visitors should understand a website’s labeling system. They should communicate that a URL (which is a document label) makes sense to them.
Links And Resources
Here are some helpful articles and tools that I use when developing an accessible website. If you know of another useful site, please let us know in the comments below.
Adobe Accessibility — Information about accessibility in Adobe products for people with disabilities
Better presentation of URLs in search results — from Google Webmaster Central
Creating Accessible PDF Documents with Adobe Acrobat Professional (PDF) from the US Veterans Health Administration
Design Accessibly, See Differently: Color Contrast Tips And Tools
Developing Accessible Websites — from the University of Washington
Dynamic URLs vs. Static URLs — from Google Webmaster Central
Lighthouse International Information & Resources — Practical tips for dealing with vision impairment
Mobile And Accessibility: Why You Should Care And What You Can Do About It — Article from Smashing Magazine
Section 508 Checklist from WebAIM
SSA Accessibility Best Practices Library from the US Social Security Administration
SSA Guide: Alternate text for images (PDF) from the US Social Security Administration
Tanaguru Contrast-Finder — Finds correct color contrasts for Web accessibility
The Elements of the Mobile User Experience — from Smashing Magazine
Web Accessibility Resources from Abilitynet.org (UK)
Web Content Accessibility Guidelines (WCAG) Overview from W3C
コメント