Accessibility For Information Architects.

Before you start

Before you start working on the IA you need to be sure what the parameters are for the build. The brief or requirements handed down by the project manager, or maybe mapped out by yourself, should specify:

• Level of accessibility: WCAG 2.0 Level A, AA or AAA, internal guidelines, third party guidelines, user acceptance criteria.

• Audience: Disability (sight, hearing, mobility and cognition), age (children, older users), location (non native English speakers), familiarity with the web (advanced, intermediate and beginner).

• Technologies: HTML5, CSS 1, 2 or 3, JavaScript, WAI ARIA, Flash etc.

‍

Layout

When accessibility is being considered design often comes a poor second to technical coding with most of the emphasis going on how to make a site semantically correct, well structured and navigable for screen reader users. It seems obvious to say that visual layout is as important as the code but often people mistake an accessible site for one that is not colorful, uses minimal images and has lots of plain text.

• Colour coding: Colour coding sections and navigation make information easier to understand for people with cognitive impairments as well as all users scan a page.

• Grouping: Visually grouping related links visually and not just under a heading.

• Good use of images: Icons to reinforce meaning, images to illustrate complex data tables, charts or meaning.

The screenshot below shows a classic design by RNIB that uses colour to reinforce IA and meaning with colour coding sections. Notice the ‘Donate’ tab is in orange with the ‘Make a donation’ box also in orange on the home page.

Structure

Failing to work out the underlying structure of a site at the IA stage is one of the biggest mistakes that can be made when building accessible sites and can lead to designs that make no sense structurally when the developer comes to code them.

Ideally you will have an idea of the content and copy so you can play around with real headings and test if they make sense within the proposed architecture. Key things to look at:

• Headings: The heading structure is like an index for the page and is used by sighted and non-sighted users alike to scan a page. The former visually and the later via keyboard shortcuts using screen readers.

• WAI ARIA landmarks: Based on your visual design you should have an idea of how WAI ARIA landmarks should work in the page. Assigning ‘banner’, ‘navigation’, ‘main’, ‘complementary’, ‘search’ and ‘conteninfo’. If you are using HTML5 sectioning elements as well as Landmarks ensure are coded in a way that does not result in verbose feedback for the screen reader user.

• Lists: Lists should only be used for true lists; content with two or more items. Resist the temptation to mark up headings also as lists. This can be confusing and verbose for a screen reader user.

‍

Headings, page titles and labels

Building up a taxonomy and documenting an inventory of copy for headings, page titles and labels ensures that content is shaped early on and can written consistently across both the main website and mobile versions of the site.

Inventories keeps wording consistent for users across sites and different delivery contexts such as mobile, tablets or TV. Starting to building the inventory at the IA stage means you can estimate the amount of space a heading or label may require on a page and help inform design. This is especially important in multi-lingual websites where translations of words may require more screen real estate.

‍

Links

How links are presented can make a huge difference to how usable a website for people with access needs really is. Early on you want to cut out repletion and ensure clarity and purpose:

• Unique links: Using hidden text within a can make repeated links such as “View’, ‘Watch’, “Details”, “Add to basket” easier for screen reader users to follow while not affecting the visual design. Work out early on where this may happen and indicate this in the wireframes.

• Duplicated links: Try to look at ways to minimise repeated links, especially around repeated links. If adjacent links repeat one another consider using a single ahref to group them together or tabindex=”-1” to remove a link from the tab order.

• Links or buttons: It’s tempting to code an element that updates content within a page as a link then style it as a button. As a general rule elements that refresh the page should be links and elements that update content within a page should be buttons. The expectation for many screen reader users is that a button will do something and not necessarily refresh the page which is the expectation for a link.

The screen shot below shows a news website and how landmarks, headings and lists might be coded around real content.

‍

Keyboard access

Establishing a keyboard tab order guides code order for developers. On traditional layouts it may be self-evident but as web pages become increasingly more complex or modular, sharing information from other pages, keyboard interaction becomes more intricate.

It’s the sighted keyboard only user that can really suffers when it comes to keyboard access. Unlike a screen reader user who uses keyboard shortcuts to jump around headings, lists, landmarks, form elements and frames, sighted users tend to navigate in a linear way.

• Visible focus: Both onHover and onFocus must be used to indicate links this could be an underline and should not be just a colour change alone. Visible focus is essential for sighted keyboard users.

• Skip links: Sighted keyboard only users are more likely to use skip links than screen reader users so these must always be visible onFocus. Factoring in space to do this is therefore needed.

• Widgets: Tab panels, carousels, accordions, complex forms, sliders all will need special care to ensure they are keyboard navigable. Use of negative (tabindex=”-1”) and zero (tabindex=”0”) tabindex can help ensure this.

• Keyboard trap: Accessing and exiting Flash content from HTML can be problematic in browsers other than IE. If the Flash is non essential consider adding a negative tabindex so that the user doesn’t get trapped in the Flash. If it is essential provide an alternative.