3.2.6 Accidental Activation

WCAG 2.1 Review: Introduction 

WCAG 2.1 now has a first public working draft and ​the working group are inviting comments and feedback via Github

As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods. ​

This post concerns a specific criterion: 3.2.6 Accidental Activation. 
To view my feedback on other criteria and more background info, go to my listing of feedback

The Criterion

  • 3.2.6 Accidental Activation
  • Suggested Priority Level: A
  • Text: For single-pointer activation, at least one of the following is true:
    • Activation is on the up event, either explicitly or implicitly as a platform's generic activation/click event;
    • A mechanism is available that allows the user to choose the up-event as an option;
    • Confirmation is provided, which can dismiss activation;
    • Activation is reversible;
    • Timing of activation is essential and waiting for the up-event would invalidate the activity.

    This success criteria applies when platform assistive technology (e.g. screen reader) that remaps touch gestures is not turned on - see proposed SC Touch with Assistive Technology.

My Thoughts

This is the kind of criterion that I like to see, it's clearly defined and very testable, I suppose it's hard to see what kind of common content would fail it, but as people are inventing more custom controls and JavaScript widgets, it's probably necessary. 

I'm happy for this criterion to be added to WCAG 2.1

3.1.7 Plain Language (Minimum)

WCAG 2.1 Review: Introduction 

WCAG 2.1 now has a first public working draft and ​the working group are inviting comments and feedback via Github

As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods. ​

This post concerns a specific criterion: 3.1.7 Plain Language (Minimum). 
To view my feedback on other criteria and more background info, go to my listing of feedback

The Criterion

  • 3.1.7 Plain Language (Minimum)
  • Suggested Priority Level: A
  • Text:
  • Provide clear and simple language in instructions, labels, navigational elements, and error messages which require a response to continue, so that all of the following are true:

    • Simple tense: Use present tense and active voice.
    • Simple, clear, and common words:Use the most common 1500 words or phrases or, provide words, phrases or abbreviations that are the most-common form to refer to the concept in the identified context.
    • Double negatives: double negatives are not used.
    • Concrete language: Non-literal language is not used, or can be automatically replaced, via an easy-to-set user setting. All meaning must be retained when non-literal text is replaced.
    • Instructions: Each step in instructions is identified.

    Exceptions:

    • When a passive voice or a tense (other than present tense) is clearer. Other voices or tenses may be used when it has been shown to be easier to understand, friendlier, or appropriate.
    • In languages where present tense and active voice do not exist, or are not clearer in the language of the content, use the tense and the voice that are clearest for the content.
    • When describing or discussing past or future events, the present tense is not required.
    • If the writing style is an essential part of the main function of the site, such as a game, a literary work, or teaching new terms.
    • Where less common words are easier to understand for the audience.
    • The content will be penalized for not conforming to a given writing style (such as a CV, dissertation, or Ph.D. proposal).
    • If there are no tools available in the language of the content that identify uncommon words, instructions that are longer then 400 words are exempt unless they directly relate to a critical service.

My Thoughts

I feel that this may be interpreted at first glance as covering all website content, but as it only relates to "instructions, labels, navigational elements, and error messages which require a response to continue", this makes it easier to handle as a Level A criterion. 

The main challenge will be ​"Use the most common 1500 words or phrases", what should the source be for that? Especially as it includes phrases, it leaves it pretty open to interpretation as to where we would get the data from. It does make it the kind of task that is best verified by automated means with manual intervention, which isn't a bad thing in itself. It would be pretty tedious and time consuming to verify this one entirely manually. 

I also prefer @mbgower's wording on the Concrete language point, it's much clearer:

Concrete language: Words are used according to their proper meanings or definitions. Metaphors and figurative language are not used unless they can be automatically replaced with literal text based on user settings.

I'm concerned that developers/testers may not have the skills necessary to identify present tense and active voice, though this can be remedied with good supporting documentation that includes many examples. 

It does seem that this would be better addressed as a revision to 3.3.2 Labels or Instructions and/or 2.4.6 Headings and Labels, though I understand that WCAG 2.1 are not revising any existing criteria. However, I feel that there is a huge amount of overlap between this and the other similar criteria. It is much better for developers, testers and automated testing tools if the criteria are very defined so that it is clear where a failure lies. As proposed, if I were to find instruction text unclear, that would fail both 3.3.2 and this new criterion. I feel that it is confusing for developers and testers when this occurs, and adds to the overwhelm felt when a huge number of new criteria are introduced. 

In summary, I don't feel it's clear enough how this differs from existing criteria, causing confusion for developers and testers. If the existing criteria cannot be revised with 2.1, I'd advise waiting until the next WCAG revision where they could be revised. 

3.3.8 Undo

WCAG 2.1 Review: Introduction 

WCAG 2.1 now has a first public working draft and ​the working group are inviting comments and feedback via Github

As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods. ​

This post concerns a specific criterion: 3.3.8 Undo. 
To view my feedback on other criteria and more background info, go to my listing of feedback

The Criterion

  • 3.3.8 Undo
  • Suggested Priority Level: A
  • Text: Users are provided with the ability to undo an action and to correct mistakes such that:
    > A user can go back steps in a process via a clearly labeled action.
    > The user can repair information via a clearly labeled action and get back to the place they were at, via a clearly labeled action, without unwanted loss of data.

My Thoughts

This is easy to understand at first glance, but I think there is too much room for interpretation. It makes it very clear that in a multi-stage form, you must offer the ability to go back. What isn't clear is whether Undo must be available once the form has been submitted.

We already have, in WCAG 2.0, Success Criterion 3.3.4: Error Prevention, which includes the fact that submissions should be reversible and users must have the opportunity to review submissions. This is a Level AA criterion, and so I'm not sure what the addition of this new 3.3.8 criterion is trying to solve, apart from putting some onus on Level A sites. 

Also, this has none of the caveats that make 3.3.4 possible, like allowing a user to phone up and cancel an order. ​

It needs clarifying how this differs from the existing criterion for Error Prevention.

1.4.13 Printing

WCAG 2.1 Review: Introduction 

WCAG 2.1 now has a first public working draft and ​the working group are inviting comments and feedback via Github

As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods. ​

This post concerns a specific criterion: ​1.4.13 Printing. 
To view my feedback on other criteria and more background info, go to my listing of feedback

The Criterion

  • 1.4.13 Printing
  • Suggested Priority Level: AA
  • Text: If content can be printed, the following are true:
    Resized: Content can be resized up to 200% without loss of content or functionality;
    Changes Reflected: User changes to letter spacing, line spacing, font family, and color are reflected in the printed content.

My Thoughts

This is one of those criteria that is a little unclear on whether the onus is on the developer or the user agent that is being used to serve up the printable version. 

From reading the documentation, I believe it is more that the developer shouldn't put anything in a print stylesheet that would prevent things from resizing or having different letter spacing etc. I'd suggest it should be renamed to "Support Printing" to make this distinction clearer.  

It feels to me like the main thing that the criterion is trying to do is prevent the cases where the developer has explicitly overridden styles in the print stylesheet that would prevent zoom and things like font changes. As suggested already on Github, this should be worded in such a way that the developer doesn't have to keep tweaking print stylesheets to cope with the shortcomings of user agents. 

Other than that, I'm pretty happy with this as a criterion, it just needs the wording firming up.

1.4.10 Linearization

WCAG 2.1 Review: Introduction 

WCAG 2.1 now has a first public working draft and ​the working group are inviting comments and feedback via Github

As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods. ​

This post concerns a specific criterion: ​1.4.10 Linearization. 
To view my feedback on other criteria and more background info, go to my listing of feedback

The Criterion

  • 1.4.10 Linearization
  • Suggested Priority Level: A
  • Text: A mechanism is available to view content as a single column, except for parts of the content where the spatial layout is essential to the function and understanding of the content.

My Thoughts

The purpose of this criterion is simple to understand for developers and testers, although there is a little wiggle room for interpretation of when layout is essential. I'd support it being renamed to "SIngle Column" though, as the titles should always be really simple to interpret. 

This success criterion is not clear enough on who provides the mechanism for reflowing content to a single column, and what that mechanism should be, though from the comments it appears that the reflow will be provided by user agents/scripts and not implemented by the developers.

The main issue is that the recommended method for testing is to switch off CSS, but this will cause content that has been hidden using display:none or similar to become visible. With responsive sites, the reliance on CSS to show / hide content has increased and so switching it off could cause very confusing displays indeed.

I feel that to make this a solid success criterion, there needs to be some form of browser plugin or script that is endorsed by the W3C for testing the reflow in HTML. Otherwise, there is too much subjectivity in the testing technique, and just switching off CSS completely will be too problematic. ​

Overall, this needs the method for testing HTML content firming up before release, but it is clear otherwise.

1.3.4 Support Personalization (minimum)

WCAG 2.1 Review: Introduction 

WCAG 2.1 now has a first public working draft and ​the working group are inviting comments and feedback via Github

As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods. ​

This post concerns a specific criterion: ​1.3.4 Support Personalization (minimum).
To view my feedback on other criteria and more background info, go to my listing of feedback

The Criterion

  • ​1.3.4 Support Personalization (minimum)
  • Suggested Priority Level: A
  • Text: Contextual information and author settable properties of regions, critical features and important information are programmatically determinable so that personalization is available.

    Exception: Information does not need to be exposed when there is not a standardized technique of exposing it in the technology or the platform.

My Thoughts

This is one of the criteria that I feel is a bit confusing to a web developer that does not specialise in accessibility. ​I don't think that it is 100% clear that what developers need to do is provide contextual information, not implement the actual personalization features from scratch. 

In fact, I'm not even sure based on the above wording whether developers are involved in implementing the personalization, or whether this is left solely to the user agent. I've commented on Github to ask. ​

The W3C's Personalization Semantics proposal does add a bit of context, "For example, assume an author can make it programmatically known that a button is used to send an email. At at the user end, the button could be rendered with a symbol, term, and/or tooltips that is understandable for this particular user. .... It could be identified with a keyboard short cut that will always be used for send".​

Apart from it possibly needing a bit of rewording, my main concern with this criterion is that the standardized technique for achieving this in HTML is not mature enough for its inclusion, in my opinion. The semantics proposal is still just an editors draft and therefore not endorsed by the W3C. I also believe that the technique for HTML implementation should explicitly reference these semantics and not leave it open to there being multiple standards. This makes it clearer for developers and testers.

While I agree that this criterion may be beneficial for users, I don't believe that there is enough developer guidance available to make this reasonable to implement right away. I'd recommend putting this aside until version 2.2/3.0, or moving it to Priority Level AAA, unless the COBA semantics can be agreed and endorsed by W3C before WCAG 2.1 is published. ​

How to detect if a user of your site has a disability

How to detect if a user of your site has a disability?

I stumbled across a question on the User Experience Stack Exchange site today, "Accessibility: How to track peoples with disabilities on websites?"

"​I want to know how much people on my website use a screen reader, use plugins for easier reading and surfing on websites, use a text browser or use else native configurations/programs for easier using the web."

It's not a bad question, after all we track all kinds of things with analytics. Google now has a stab at estimating the gender and interests of your site visitors so this is a logical step on from that.

Now because the questioner doesn't provide us with ​any more context than the snippet above, I'm going to base my response on the assumption that they want to know in order to influence product decisions.

Just as I check the analytics of a site to see if it still makes sense to support IE7 (hell no)​, maybe knowing how many users have disabilities could help you with prioritising your development backlog or (unfortunately) deciding whether to bother testing for accessibility at all.

OK, so what would we test for?

Now that we think we have captured the mindset of the developer here, let's break this down a bit further, what can we test for in our new, fancy​ disability detection code?

Things that come to mind:

Screen Reader Use
A pretty obvious one to check for, these users definitely tick the box for needing a site to be accessible.

Navigating with a keyboard only
​If the user doesn't use the mouse at all, they probably count here too.

Browser zoomed in
People tend to zoom in if they're struggling to read. Maybe they would use magnification software. Hmm, this is starting to look tricky to test for.

Colour blindness
Oh, um, not sure how we can check this one. It's important though.

Deaf and hard of hearing
I guess these people might struggle with some content...

The elderly? Young children? People who have broken their arm? The dad holding his baby while trying to shop?

Once you head off down this train of thought, it's pretty clear why disability detection is a bad idea. 

Accessibility isn't solely about disabilities

It's often described (and I'm totally guilty of this too) as "enabling those with disabilities to use your website".

I like to flip that on it's head and state that it's all about making the web accessible to all. There's a subtle difference in there and it's where people like our dad trying to shop online when holding his baby come in. 

Maybe it's easier for him to just browse using the keyboard and not the mouse. More importantly for your business, maybe he's more likely to buy from your shop if it's easy for him to just navigate with the keyboard.

If you start searching for statistics on who will benefit from you making your site accessible, you're always going to come up with a number way lower than the reality. Loads of people benefit from accessibility. 

You know the right thing to do.​

How to detect if a user of your site has a disability #a11y

Click to Tweet

Skip to Main Content

Developer guide - skip to main content

Ever come across a Skip to Main Content link? The name is pretty self explanatory. It allows a keyboard-only user to bypass navigation menus that are tiresome to navigate through without a mouse, and takes them straight to what they want – your content.

As a mouse user you might be wondering why it’s worth including this in your site or why we’ve gone to the trouble of even making this guide.

Here’s a challenge for you.

Go to YouTube. Using nothing but the keyboard play the very first video on the page. That’s a lot of tab clicking, right? Now imagine that this is the only way you have to use a website. Makes you want to tear your hair out, doesn’t it?

It’s not just YouTube that has this issue, please don’t think I’m picking unfairly on them. This is a similar experience across the web. Try johnlewis.com. They’ve at least tried. They have a Skip to Main content button. It just doesn’t work.

Clearly, even some of the best developers need a little help with this one.

So please, go ahead, watch the following videos to learn more about this feature, the need for it and how to best implement it. We’ve separated out the developer section so that those of you who want to jump straight into fixing your websites, can.

This first video is for everyone, detailing the problem and what can be done about it.

How-to Guide for Developers

This next video is aimed more at the developers out there looking to fix their websites.

There are a couple of techniques used in the videos that have been covered elsewhere on the blog. If you want to look more into these please follow these links:

Screen Reader Only Content >>

I had to make the “Skip to Main Content” link visible to screen readers but not to sighted users, which I achieved using CSS.

Adding Tab Focus to the Content >>

By default, you can’t set tab focus to the main content <div> element. I used the tabindex attribute to make it possible for the JavaScript to set focus to it, even though you can’t tab to it manually with the keyboard.

Simple Solution – Use My Plugin

Last thing, I promise. If you’re a developer and you’re really busy (and let’s face it, who isn’t?), we even have a ready-to-go plugin for you hosted by our friends over at GitHub. Simply implement this on your website using the instructions on this page:

Skip to Main Content Plugin >>

Skip to Main Content Plugin

skip to main content plugin

When you’re navigating a website with the keyboard, it can be really tedious to have to tab through all the navigation links on every page. I’m going to present a solution that gives users the ability to skip straight to the main content of the site.

Background

I'm building a series of plugins to help you make accessible websites. The main reason websites aren't very accessible is usually that developers don’t have the time to focus on it, so a library of plugins feels like the best way to help out. They’re all open source and I’d love the community’s feedback on how to improve them.

Demo

WordPress already has Skip to Main Content functionality built in to some themes, so you may not need this plugin. For demo purposes, I’ve disabled the WordPress feature and installed my own plugin on this site.

To try it, hit the tab key and you’ll see the skip link. When you press enter, it jumps the tab focus to the main content of this page, so you don’t have to go through all the menu links.

Get it for your site

The plugin depends on jQuery version 1.9+.

Download the latest JavaScript and CSS files from GitHub and reference them in the <head> element of your site, after the jQuery reference. For example:

<script type="text/javascript" src="/js/my-accessible-website-skipnav-1.0.0.js"></script>

<link rel="stylesheet" href="/css/my-accessible-website-skipnav-1.0.0.css" type="text/css" />

To use it, select the main content container of your site with jQuery and call the maw_skipnav function. Make sure you put it in a document.ready event handler, like this:

<script type="text/javascript">
$(document).ready(function () {
$("#content").maw_skipnav();
});
</script>

Options

There are a couple of options you can pass in to customise the behaviour of the plugin.

skipLinkText: By default, the skip link says “Skip to main content”, but you can change this if you’d like it to say something different or for internationalisation.

linkAlwaysVisible: The default behaviour of the plugin is to hide the skip link until it has focus, but if you set this to true, it will always show.

Here’s an example with the options:

<script type="text/javascript">
$(document).ready(function () {
$("#content").maw_skipnav({
             skipLinkText: "Skip the menu",
             linkAlwaysVisible: true
         });
});
</script>

Customisation

If you want to change the appearance of the skip link, it has the CSS class
maw-skipnav-skiplink

The Tabindex Attribute

Changing the Tab Order

The tabindex attribute is used to define the order that you can tab through elements on a page. Most of the time, the default tab order is fine, as it follows the order of elements in the HTML.

For example,

<input type="text" tabindex="1" />

… will take tab focus before

<input type="text" tabindex="3" />

… regardless of where it is positioned in the HTML.

Usually it’s much better to reorganise the HTML than to start adding tabindexes though, as it is just one more thing to maintain.

 

Making it possible to focus <div>, <p> and <span> elements

You can’t usually tab to elements that aren’t links and buttons. You can change this by setting the tabindex value on elements like <div>, <p> and <span>.

Tabindex 0

By setting the tabindex to 0, this means that the element may be tab focused, and you can tab to it in the default order based on where it is in the HTML structure.

Tabindex -1

If you set it to -1, this is a special value that means you can set tab focus using JavaScript, but the user won’t be able to tab to it using their keyboard. I used this in the Skip to Main Content plugin.

Page 1 of 2