Ashley Sheridan​.co.uk

Tags:

In January there was a recent update to the WCAG that introduced some changes in what's expected of you as a developer to make your web content accessible. The majority of these are fairly obvious and straightforward, with some nice additions that enhance accessibility on smaller hand-held devices.

1.3.4 Identify Common Purpose

Conformance level: AA

The general idea behind this is to provide better autocomplete support for users to avoid them needing to continually enter the same kinds of information repeatedly across different websites. By utilising the autocomplete attribute of form elements better, the user can allow their browser to assits them with filling out forms.

The WCAG has created a list of autocomplete fields that will help give your web forms conformance to this accessibility criterion, although personally, I'd advise against using some of the credit card autocomplete details purely from a security standpoint, as there's not yet a manner in which these details can be guaranteed secure within a browsers autocomplete storage.

1.3.5 Identify Purpose

Conformance level: AAA

In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.

The general idea of this is that content that is more symbolic in nature (e.g. symbols on a toolbar) are a language of their own and this conformance critera allows a user to effectively "translate" the symbols into something more localised to themselves.

This can help users with cognitive disabilities who may have difficulty understanding new symbols, especially if the meaning of that symbol has been conveyed by other symbols elsewhere (e.g. on other websites). By using ARIA ePub mappings and using Microdata you can help ensure that your code conforms to this requirement.

1.4.10 Reflow

Conformance level: AA

The reflow criterion is aimed at ensuring your web content is still accessible when zoomed in to about 400% without requiring the user to pan scroll about the page.

For example, if a user zooms into your website at 400%, they should not then have to scroll in both directions to view all of the content. That content should reflow accordingly and allow the user to access it all while only scrolling in one dimension (if scrolling is necessary at all)

1.4.11 Non-text Contrast

Conformance level: AA

The non-text contrast criterion is intended to ensure that all non-text content (e.g. content that conveys some meaning to the user, but is not purely text itself) has enough contrast to make it distinguishable to users with visual disabilities.

One of the key examples highlighted by the WCAG of non-text contrast is that of form elements, which have a visual element that is not solely text. By giving input fields a different contrasting background colour, or a contrasting border, the element will stand out enough for people with impaired vision. As with other contrast recommendations, a good way to test this is to look at the website in purely greyscale.

1.4.12 Text Spacing

Conformance level: AA

This one is very specific in the details, and it's best to quote the original feature verbatim:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are used.

Basically, if the language/script supports it, and the listed text styles are applied, there should be no loss of functionality incurred by the end user. The easiest way to test this would be to apply the following styles to your website and test the affects:

1.4.13 Content on Hover or Focus

Conformance level: AA

Showing and hiding content based on whatever on the page has the cursor over it is generally not been a recommended practice, but this helps highlight some of the issues surrounding that, particularly with the users hover being able to move over the now-shown content without it disappearing again immediately. This is aimed at things like fancy drop-down menus (not select elements, which are a different entity) where a menu or sub-menu is shown when the cursor is hovered over a trigger.

There are little changes to showing content based on the focus of another element, as existing accessibility rules really should cover most cases. The one addition for both focus and hover based content is that there should be a way to dismiss that new content without moving the pointer or focus, unless that content is communicating an error or is not obscuring other content on the page. There are two suggestions to allow this to be possible:

1. By pressing escape on the keyboard
2. By offering a close button

This presumes a level of persistence on the content, such as with a modal. Both methods may be used together.

2.2.6 Timeouts

Conformance level: AAA

Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.

This is just general good practice, and the kind of common-sense idea that's visible on everything from Google Docs to local government forms. A simple message should suffice, but you could even get a bit more clever and have an internal timer that is reset any time the user takes an action on the page, then when the time hits a preset limit, show a message to the user. The notifications API could even be used for this, but be careful of spamming the user to allow notifications without any kind of justification.

2.2.7 Animation from Interactions

Conformance level: AAA

Any animations on the page that are the direct result of something the user did should have the option to be disabled. Large amounts of animation can have a detrimental affect on some people due to their disabilities, so it's generally been recommended to keep animations minimal and unobtrusive for general purposes.

If the animations are created and triggered purely by CSS then consider a class set somewhere close to the root of the DOM that can be used by those animations when they need to be disabled:

Alternatively you could apply the paused state to all elements and mark the style important, but this might be possible to override in your own styles with a more specific selector (also marked !important). The first way is more explicit within your own code, so less likely you will make a mistake.

2.4.11 Character Key Shortcuts

Conformance level: A

This is one of the few Level A critera added to the WCAG 2.1 update. The main aim is to prevent your keyboard bindings from being a bar to entry for speech users or users who may not have great keyboard dexterity and accuracy.

The given scenario for character key shortcuts is where a speech user might be dictating commands to their computer, and accidentally trigger bindings that you have added to your website.

In order to conform to this requirement, you can do one (or more) of the following:

• Allow the user to disable your custom shortcuts
• Allow the user to remap your custom shortcuts
• Change your shortcuts to a combination, e.g. instead of the letter a triggering the action, Alt + a could be used instead
• Ensure your key bindings are only active when a certain component has focus

2.4.12 Label in Name

Conformance level: A

When the text that is displayed to the user for something is different from the text that is made available as part of the accessibility attributes, there can be difficulty for some users relying on less typical navigational methods. For example, someone who is using speech to control their navigation may read out what they believe to be the label for an element, e.g. to follow a link or 'click' a button. If the accessible name is different from the one they see, then the browser will not have the expected behaviour.

So, for example, imagine you have a some links offering a document to download in different formats:

Now, within the accessibility tree, these links will present themselves as "PDF Download" and "Word Doc Download" respectively, but their visible label is just "Download" for for both. The disconnect here means that a person using a speech browser may issue an instruction like "click download", but the browser would not know how to behave.

2.5.1 Pointer Gestures

Conformance level: A

The intent of this one should be obvious. Given that not all users have the ability to use a pointing device or can perform gestures with touch controls, there is always a need to allow interaction through other means. The criterion does mention that in some cases it may be essential (e.g. for drawing a secure lock pattern, similar to that used on phones).

2.5.2 Pointer Cancellation

Conformance level: A

When on a website, it is possible to accidentally interact with elements of the page, such as by accidentally touching the screen with a finger, or clicking down with a mouse on a link. For many users, the typical behavior once they've realised they've triggered the down event is to move outside of what appears to be the active area and release the mouse button (or remove their finger from the screen). If you attach actions to the down event, then the user does not have this opportunity.

If it's absolutely necessary to attach actions to down events, then use a confirmation process, or allow the action to be undone.

2.5.3 Target Size

Conformance level: AAA

As some people have difficulty using a pointing device, it can help to make the hit target of interactive elements large enough that they can use them. For example, a sufferer of Parkinsons may be using a mouse, but the jittering effect of their hand movements might affect their fine motor control in their hands. By ensuring that checkboxes, buttons, links, etc, on your pages are at least 44×44px, you give them a much better chance of interacting with your website successfully.

There are some allowances for exceptions, such as when:

• The same action is available on the same page elsewhere through an element that is at least 44×44px
• The target is within a sentence or block of text
• You have no control over the size of the element and it is set by the browser
• or, It's absolutely necessary

2.5.4 Concurrent Input Mechanisms

Conformance level: AAA

Users may be browsing your websites using a wide mix of differing navigational devices, such as keyboards, mice, dictation, touchscreen, etc. You should not restrict input to any one of these methods unless it's absolutely necessary.

2.6.1 Motion Actuation

Conformance level: A

As browsing on handheld devices becomes more popular, the pool for people having difficulties with websites and web apps that are using features like a phones accelerometer exclusively for certain types of navigation becomes more prevalent.

If you rely on such features for navigation, and operation, then you should look to include other means of interacting with your website, unless it's absolutely necessary.

2.6.2 Orientation

Conformance level: AA

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

This is pretty self-explanatory, and should be general common-sense. People will orient their devices however they like, so your websites should work in whichever orientation suits them best. If you're making your website fully responsive, then this should typically not be a problem.

3.2.6 Status Changes

Conformance level: AA

It may often be necessary to give the user feedback on the status of things, such as the result of saving some details, or making a purchase. There are appropriate ARIA attributes for this purpose to help identify such status messages in a way that people can be made aware of them in an unobtrusive manner.

Consider the situation where a blind person has added an item to their shopping cart from a list of search results. A possible status message could be confirmation of the addition and an update of the number of items currently in their shopping basket. Calling immediate notice to such a message could interrupt their browsing, as focus would shift to the notification and they would lose their place in the list. By careful use of things like aria-live="polite", screen readers can inform the user only when they have become idle (e.g. after a short period of inactivity). Effectively, this is like waiting for someone to finish speak before saying something yourself, rather than just interrupting their conversation.