Accessibility Best Practices for eCommerce Sites

Gian Genovesi

With an infinite number of moving pieces involved in implementing, configuring and running an eCommerce website, it’s not at all uncommon for something to fall through the cracks. Building an easily accessible website is frequently thrown to the wayside when, in all reality, putting in the extra effort on the front end will certainly save headache later. Very easily maintained standards can drastically improve the user experience of disabled users, increase SEO and mitigate the risk involved with a site not adhering to accessibility standards; first a little background…

Accessibility Standards and Their Governing Bodies

Currently there are three generally accepted governing standards used to gauge site accessibility; these are as follows:

Section 508

Section 508 refers to an amendment to the Rehabilitation act of 1973. It outlines minimal standards for government sites and sites that refer to government material. It is a generally accepted baseline for accessibility standards although it doesn’t give much specificity or guidance around the various types (flash, static content, etc) of online content.WCAG 2.0
WCAG standards outline accessibility requirements for static content. Many of these standards are derived from those outlined in Section 508 adding specific emphasis on static website content.


ARIA, or Accessible Rich Internet Applications standards, are used to outline best practices for accessibility in dynamic website content. ARIA standards are the newest of the bunch, and the least widely known. They only to tackle dynamic content (flash, etc). It’s important to note that of these standards only one of them is an actual law, meaning a lot of the compliance determination lies in their interpretation – the most famous of interpretations being the National Federation of the Blind v Target. However, that being said, creating an accessible website can drastically improve the browsing experience of Google crawlers and disabled users alike.

The Guidelines

Assign All Images Alt Tags

The W3C’s HTML recommendation requires the use of the alt attribute / tag on all images. While all important images should have brief, descriptive alt text, unimportant images (such as purely decorative or spacer graphics) or redundant images should use null alt– i.e., alt=”". Using well devised alt tags throughout the site also provides SEO benefits.

Ensure Links are Clear, Descriptive and Context Independent

Screen readers can sort links into list boxes for easy browsing. If a link is worded properly, the user will still be able to identify the link and the target to which they will be navigated; to satisfy this accessibility requirement, make sure that link verbiage is clear, descriptive, and context independent. For example, avoid links that are worded simply as “click here” or “read more”. Instead use descriptive language, such as “Learn more about choosing a diamond”, or “Read more about diamond ratings”.

Label Forms

Forms need explicitly associated HTML labels. Explicit labeling is the only way to ensure that visually impaired users will hear the correct label for inputs. HTML’s label element and associated attributes can be used effectively to make most forms accessible. In a basic application, the label element will contain a form attribute that is matched exactly with the id attribute that is applied to the form element itself. Valid values for these attributes are alphabetic characters, dashes, underscores, colons and periods; spaces are not permitted.

Utilize Non-Conflicting Contrast Levels

In order for users who are visually impaired and maybe not totally blind to be able to see all the information on a web page, authors should provide enough contrast in foreground and background color schemes. Problematic contrast schemes may not be easy to spot. WCAG 2.0 provides guidance on determining sufficient contrast levels, as well as techniques for testing for sufficient contrast.

Provide Device Independent Focus

All actions on a website should be achievable in a device-independent manner – in other words, not just with a mouse but with a keyboard. This will not only benefit blind users who rely strictly on keyboards to navigate the web, but also users with mobility impairments or physical disabilities prohibiting them from using a mouse. An extremely common example of a situation where device independence can be a key differentiator is the use of Javascript to create mouse-over drop-down menus. When using the onmouseover and onmouseout event handlers, for example, including the onfocus and onblur event handlers to ensure that the same functions can be achieved without using a mouse is imperative. For situations where onmouseover and onmouseout are used to change aesthetics onfocus and onblur are not necessary. In addition, ensure that selecting the top-level link (the element that, when focused on, exposes the submenus) leads to a page where the submenu links are visible and can be selected. See the WCAG 2.0 techniques document for more information about device independence.

Supply Method for Bypassing Repetitive Links / Content

On a website that has repetitive navigational links, it’s always best to provide a method for users to bypass those links. One technique to consider for bypassing large groups of links is the use of landmark roles found in ARIA. Landmarks can be used to programmatically identify common types of content in a consistent way, including search tools, banners, and the main content area of a page. This markup has no effect visually to the page, but allows screen-reader users one-key access to easily move from one area of a page to the next: as an example, JAWS (an accessibility tool) users can quickly move through landmarks using the semi-colon (;) key. The addition of landmarks to the navigation, search and main content areas of a web page can provide screen-reader users with a convenient method to scan the page and to move quickly from one area to the next.

Proper Heading Use

Semantically, headings are used to denote the start of a new section on a page. However, for screen-reader users they can also provide a mechanism to efficiently scan the page in a manner similar to a sighted person, dramatically reducing the time required to interact with a website. HTML headings can be styled using CSS, and can be made to fit the existing page design. Images can also be used as headings, provided they are accompanied by the appropriate alt text (see above). A good rule of thumb is, if text is used as a section break or title, it should be structured as a heading. Properly implemented heading structure provides a direct SEO benefit, especially with targeted keywords used in headings. However, over use of the heading tags will have the opposite effect. The lesson – use headings exactly like titles (h1) and section headers (h2, h3, etc) in school papers.

Provide Accessible Tables

All data tables need to have explicitly labeled header rows. If headers are not clearly indicated, screen readers are forced to guess at X- and Y-axis information to help orient the user in the table. Authors should therefore guarantee accuracy by using appropriate table markup.

Provide Accessible Multimedia

All multimedia must have accessible equivalents for disabled users. These equivalents may be provided as synchronized captions or video descriptions. A transcript may be considered an accessible equivalent in some cases such as audio-only content. That being said, if the site must adhere to Section 508 requirements, synchronized captions are a requirement. HTML5 now offers a new method for delivering audio and video clips. The new video and audio elements make it simple to embed multimedia directly into web pages without the use of plug-ins. Caption support, provided by the new track element, is currently under development. While many browsers already support the video and audio elements, track has not yet been implemented. In the meantime, some authors have developed Javascript workarounds adding synchronized captions to HTML5 videos. LeanBack player is an example of a method of providing Javascript caption support.

Ensure Dynamic and Interactive Elements are Accessible (e.g. Flash)

Flash elements must be accessible to screen-reader users. All buttons, controls, forms, etc identifiable and controlled by screen readers and by keyboard-only users. IE provides the best keyboard accessibility to Flash, however, at times, it still may be inadequate for certain screen readers unless elements are properly labeled.


While user experiences will continue to improve, adhering to these current best practices and guidelines will ensure that each visitor will be provided with the same usability, and that site crawlers will categorize and scan content with greater ease; this will guarantee sites are welcoming to both search engines and, most importantly, everyone.

A Great Offer, Just a Click Away

Lorem ipsum dolor sit amet, consectetur adipiscing elit

Subscribe by Email

No Comments Yet

Let us know what you think