Author Archives: Roger Hudson

Automated kiosks and accessibility

by
, ,

Automated kiosks are a relatively new method of delivering information and services, however in the last few years they have been increasingly used for a wide range of purposes including, providing government information, check-ins at the airport and hiring videos.

In Australia, and elsewhere, it appears that currently there are few government guidelines or regulations that relate specifically to the accessibility of kiosks. However, in a number of countries (including Australia) there are guidelines relating to the accessibility of ATMs and ITMs (information/transaction machines) and these guidelines are being increasingly applied to kiosks.

In Ontario, Canada, the Integrated Accessibility Standards Regulation (IASR) requires government and public sector organizations to include accessibility features in self-service kiosks they design or buy. While urging all organisations to consider the accessibility of their kiosks, it appears that the IASR does not specify which accessibility features must be included in self-service kiosks.

In the US, recent action to improve the accessibility of kiosks has taken several forms. At the end of 2013, the US Department of Transport announced it was amending its rules to require US and foreign airlines to improve the accessibility of kiosks over a period of time. However, the National Federation of the Blind, felt that the proposed changes were insufficient, “by allowing continued discrimination against blind passengers based on spurious assertions by the airline industry that making kiosks accessible will cost too much and take a decade.” In January 2014, the NFB filed a law suit against the Department of Transport asking the court to set aside the new rules because, “it denies blind people’s full access to the kiosks.” (http://skift.com/2014/01/22/national-federation-of-the-blind-sues-dot-on-airline-kiosk-access/)

Also in the US, the Lighthouse for the Blind and Visually Impaired (LBVI), and others, filed a class action lawsuit in 2012 against Redbox claiming their self-service DVD kiosks with touch-screen controls exclude people who are blind or visually impaired.  According to Michael Nunez, an attorney with Disability Rights Advocates, “This is a trend not unique to Redbox. Seeing kiosk technology propagated through airports, restaurants and shopping centers – it’s a big concern that these technologies have a design that doesn’t consider accessibility.” (https://www.ssbbartgroup.com/blog/2012/01/16/redbox-sued-over-inaccessible-kiosks/)

The European Union (EU) is funding a range of projects in the Digital Agenda for Europe program. This includes providing half the budget for to the “APSIS4All” project which aims to design personalised interfaces, including contactless cards, to help overcome existing accessibility barriers. Currently there are trials of cash dispensers in Spain, and ticket vending machines in Germany as part of the project.

In Australia, it appears that concerns about the inaccessibility of kiosks have been on the agenda of the Human Rights Commission since at least 2000:
“Over time, the distinction between an Automatic Teller Machine and an information kiosk will continue to blur, making access to cash and financial services potentially more complex. Currently, it is due to the relatively limited range of services and options offered by current ATM units that allows some people with disabilities to perform some ATM transactions with reasonable levels of success. Of course, as discussed [elsewhere in this paper], this access is still difficult, may result in additional expense, and usually relies heavily on the person’s memory.”

“Accessibility of electronic commerce and new service and information technologies for older Australians and people with a disability.”
Human Rights and Equal Opportunity Commission, 31 March 2000.

In general, it appears that most of the accessibility concerns relating to automated public kiosks fall into two broad categories:

  • Kiosk environment and structure: This includes the location of the kiosk and providing ease of access for all people, including wheels chair users, the elderly and people with impaired vision. Also, covers the physical structure of the kiosk, such as the height and angle of the screen and keyboard, as well as the provision of headphone outputs and in some cases assistive keyboards.
  • Screen interface: This includes the size and colour of the text and buttons on the screen, clear identification of form inputs, the use of language that is easy to understand, and the provision of audio alternatives for all information or functionality conveyed by images or text. In addition, there should be a facility for people to increase the amount of time needed to complete a task and the ability to review, verify or revise any transactions.

It appears that the physical structure of kiosks, and the environment in which they are used, are often covered by government regulations concerning disability access to facilities in the built environment. However when it comes to the accessibility of the kiosk interface, there are few if any specific regulations, but WCAG 2.0 appears to be a good starting point, particularly if the kiosk is basically providing access to online content such as government information, ticketing/timetable systems and banking services.

In the opinion of the Australian Human Rights Commission, all online services are covered by the Commonwealth Disability Discrimination Act (DDA) and should be accessible:
“The provision of information and online services through the web is a service covered by the DDA. Equal access for people with a disability in this area is required by the DDA where it can reasonably be provided. This requirement applies to any individual or organisation developing a website or other web resource in Australia, or placing or maintaining a web resource on an Australian server. This includes web pages and other resources developed or maintained for purposes related to employment; education; provision of services including professional services, banking, insurance or financial services, entertainment or recreation, telecommunications services, public transport services, or government services; sale or rental of real estate; sport; activities of voluntary associations; or administration of Commonwealth laws and programs. All these are areas specifically covered by the DDA.”

Australian Human Rights Commission
World Wide Web Access:  Disability Discrimination Act Advisory Notes (Version 4.0)

Information resources

Social Inclusion, Social Responsibility and Goldilocks

by
,

GAAD Talk 2013

Intro:

In Australia, we have been discussing for years how we might provide greater assistance and care to those with disabilities. Last year, the government proposed a National Disability Insurance Scheme (NDIS), and this stimulated considerable debate, particularly about how it would be funded.

Two weeks ago, when asked if I would like to speak at the A11ybytes Global Accessibility Awareness Day (GAAD) event in Sydney, I suggested that rather than talking about the web, I would like to look at the question of social responsibility. I cited the proposed NDIS, which was basically in limbo at the time, as an example of our need to understand that social justice improvements usually come at a cost, that we should be willing to make.

The advertised title for the talk was, “Social Inclusion: Social Responsibility”.

GAAD presentation transcript

I have changed the name of this talk to Social Inclusion, Social Responsibility and Goldilocks

Last year, when the government expressed their desire to introduce a national disability insurance scheme, most people said what a good idea, followed by shaking heads and mutterings about the cost. The opposition started to run the “new great big tax” flag up the pole, and the government immediately ruled out the idea of a tax increase or levy.

Well, “a week is a long time in politics”, and it looks like we will now have disability care system, supported by both sides of parliament and, initially at least, it will be paid for in part by an increase in the Medicare levy.

It is great that we finally have a government with a couple of ministers willing to take political risks for the rights of the disabled, but thanks shouldn’t go to them – rather to the many in the disability sector who fought for this change; working not for days, not for weeks or even months, but for years and years.

Most in the community have expressed support for the disability care initiative; then of course there’s the man from Myers. Well, if as a result of this levy, spending in your shops falls rather than rises, let me suggest you look more closely at what you are selling and your attitude to customers, all customers, which of course includes some with disabilities.

Over the last couple of decades, one of the biggest advances in social justice has been the move from what could be basically called a ‘charity model’, where favours are dispensed to those in need, to the notion of ‘social inclusion’, where all people feel valued, their differences are respected, and their basic needs are met so they can live in dignity.

Now, about rights: We like to rejoice in the notion that we are all ‘created equal with inalienable rights’, but this hasn’t always been the case. Not that long ago the prevailing attitude to people with disabilities was “out of sight, out of mind”, except of course for those special, once a year, fund raising events.

Mounting pressure over a couple of decades from those in the disability sector combined with political and legal action, including the introduction of the Disability Discrimination Act by the Hawke Government in 1992, saw attitudes change.

But, social progress and advances in human rights usually cost money.

Not that long ago, women who worked in the public service had to give up their jobs when they got married and those women who did work, got paid less than men doing the same job. Of course, things aren’t perfect today, but at least women now have a legal right to work regardless of their marital status, and they have the right to receive equal pay for equal work, even if it does mean a rise in the overall wages bill of government and industry. The vast majority of Australians today wouldn’t have it any other way, and some young people are truly amazed when they hear women didn’t always have these rights.

When women were being denied equal pay, many aboriginal workers in rural Australia weren’t being paid at all, receiving handouts of flour, sugar and tea instead. When the government finally introduced laws awarding equal pay to Aboriginal workers, and the black stockmen at Wave Hill station went on strike to get what they were due, many station owners complained about the cost of the equal pay decision, predicting it would be the death of the cattle industry in Australia. Most in the general community though, felt that this form quasi-slavery had to end, even if it meant that the price of a steak went up by a few cents. And of course, the industry survived.

In a more general sense, most of us believe that everyone has a right to education provided through government funded schools, and we should all be able to receive good health care regardless of how rich or poor we are.

If we are to continue to advance as a society the disabled in our community and their carers should also be able to enjoy the same rights as the rest of us, the right to education, employment, health, etc: In short, the right to a life of dignity that the community as a whole should be willing to fund.

People should not be denied the right to participate in education or work because they can’t afford the assistive technologies they rely upon. Nor should the lack of funds deny someone the rehabilitation treatment or the care they might require. Among my extended family and friends there are people with disabilities whose lives today would be immeasurably better if something like the NDIS had been introduced 10, 20 or 30 years ago.

Over the last year, shadow treasurer Joe Hockey, has been calling for an end to the ‘age of entitlement’ – a little rich, in my opinion, from a man who was a Minister in the previous conservative government that managed to find a way to give out billions in tax cuts and benefits to those who were generally well off, but felt that providing more for the some of the most marginalised in our society would place an unnecessary strain on the budget. Hockey and Abbott expressing support for Disability Care now is terrific, but seven years ago when they were wearing the finance trousers, why didn’t they put their hands into pockets that were then stuffed with cash?

However, I do think the general point Hockey raises is relevant – we do need to think about how much things cost and who pays for them: But, I also think there is a great difference between what people see as ‘entitlements’, and what are the ‘basic rights’ of all people.

Rights are not God given, as some might suggest, they come from a recognition by humanity as a whole that all people should be treated equally, and sometimes these rights are enshrined in laws like discrimination acts to give them a little more force.

‘Entitlements’ however always come from government, often to promote the cause of greater social justice with things like unemployment or disability payments and Medicare. But sometimes ‘entitlements’ are given for crass political reasons in order to gain votes: A notable example being negative gearing for investment properties, which costs the government about the same in lost revenue as what it expects to raise for disability care through the increase in the Medicare levy.

The other day I overheard a very interesting conversation between two guys. One was going on about how unfair it was that his retired parents had to hide fact that they owned an investment property or two so that they were still able to get the full pension.

His mate agreed, mouthing some of the standard shock-jock arguments; ‘they worked hard all their lives and are entitled to their pension’ and of course, ‘it’s the government, they would prefer it if people sat around doing nothing, rather than trying to get ahead’. The conversation then turned to the NDIS and I leaned at little closer.

‘Not sure about this levy’ said one.

‘Yeah’, said his mate. ‘Fucking government, all they can do is raise taxes, and then waste the money.’

Now on one level this conversation is absurd, or even funny; but I suspect at its core it does offer us an insight into the thinking of many in the community. Today, is seems that nearly everyone, regardless of their needs, feels ‘entitled’ to government assistance, yet years of neo-conservative propaganda about the evils of wasteful big government and endless promises of tax reductions has meant no one is willing to pay for it.

Maybe things would be better if some of these feelings of ‘entitlement’ were balanced by greater social responsibility.

When it comes to the discussion about improving accessibility, it’s time we moved from blaming others such as governments and industry, to a greater acceptance by us all, that we need to place a higher priority on disability rights.

I think that as citizens of a civilised society we need to confront head-on that we have responsibilities, which should include a willingness to pay whatever it takes to ensure that those with disabilities are treated fairly.

I don’t know how many of you noticed the sad story a couple of days ago about how 70 millionaires, with a combined income of nearly 200 million dollars, had earned so little that they didn’t have to pay any tax at all. But, somehow they still managed earn enough to pay their accountants $33 million for creative writing services.

What they did was probably within the law, but was it socially responsible? I think not.

Unfortunately, I suspect many in the community would probably praise rather than condemn this sort of behaviour. But I am sure, that if 70 people on the disability pension were able to arrange their affairs so that they could get $200 million out of the government in one year, the shock-jocks, tabloid press, and the general community would go ballistic.

Contrary to what you hear in the media all the time, we don’t pay too much tax, when compared to the rest of the world, and it is sad that so many people think it is clever or cool to avoid doing so. It’s really very simple, without taxes there won’t be government services.

Remember Goldilocks? The pretty girl in nice clothes with ringlets in her hair who’s a little hungry and so feels entitled to help herself?

A selfish, social deviant, with little concern for the welfare of others: She breaks into the poor bears’ house, steals their food, trashes the joint, and then leaves.

A socially inclusive society is a society that cares equally for all its members.

Social responsibility requires a willingness to pay your fair share in this process.

Don’t be a Goldilocks, it’s not cool.

Thank you

Accessible Forms 2: Required Fields and Extra Information

by
, ,

The second in this series of articles about improving the accessibility of web page forms:

  • Accessible Forms 1: Labels and identification
  • Accessible Forms 2: Required fields and extra information
  • Accessible Forms 3: Error identification and correction
  • Accessible Forms 4: Keyboard access and focus order
  • Accessible Forms 5: Improving Usability with JavaScript

This article will look at different ways to mark-up required (mandatory) form fields and provide additional information that maybe necessary to understand or correctly complete a form.

Providing adequate instructions and helping avoid mistakes are clearly aids to accessibility, and necessary for compliance with several WCAG 2.0 Success Criteria, including:

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

3.3.5 Help: Context-sensitive help is available. (Level AAA)

NB: The sample forms were tested using JAWS 13, WindowEyes 8.1, and NVDA 2012.3 with recent versions of Internet Explorer (IE) and Firefox (FF). Also tested with Apple VoiceOver using Safari.

Identifying required form fields

Sometimes you have to complete certain parts of a form; that is, some inputs are required or mandatory. Required form fields can be indicated in a variety of ways, but the method used must be perceivable with different senses so can’t rely solely on a difference in the colour, size or position of those fields that must be completed.

There are two main components to indicating required form fields:

  1. At the beginning of the form, clearly state that some form fields are required, and provide a key to how the required fields will be indicated (NB: The key to identifying required fields should not be at the end of the form).
  2. Identify the required field with words or a symbol that can be programmatically associated with the field. This will usually mean the required field indication is contained within the label element.

How to indicate a required field

The three main ways of visibly indicating a required form field are:

  • Using the word “Required”
  • Using an inline image (often a graphic star) with an appropriate alt attribute (e.g. “mandatory form field” or “required information”).
  • Using the keyboard star (asterisk) symbol

Whichever method is used, the word, symbol or image must be part of the label associated with the form control (e.g. input, select, checkbox, radio button). For example:

 <label for="street">Street Address (required):</label>
 <input type="text" name="street" id="street">

Using HTML5 and/or ARIA

HTML5 and WAI-ARIA provide other ways to specify required form fields, but browser and/or screen reader support for these techniques is variable.

HTML5

With HTML5, the word “required” is included as an attribute of the input or select element, for example:

 <label for="address">Address:</label>
 <input type="text" name="address" id="address" 
 required>

Use of the HTML5 required attribute will result in some screen readers identifying the field as required when used with some browsers. However at this time, not all screen readers and/or browsers support HTML5. For example, the required field above will be identified by NVDA 2012.3 when using Firefox 19, but not when using Internet Explorer 9; And, is not identified by WindowEyes 8.1 with either browser.

When a required form field is not completed, the HTML5 required attribute will also cause some browsers (e.g. Opera, Chrome and Firefox) to highlight the field and generate an error message when an attempt to submit the form is made.

Screen shot of form field with HTML 5 invalid entry message

screen shot of HTML5 required error indication

For web users who don’t use a screen reader, identifying required form fields, which have not be filled in correctly, only after the form has been completed is not very useful. And, the accessibility and usefulness of error messages such as these is questionable for screen reader users.

ARIA

aria-required is also an attribute of the input or select element, however with ARIA it is necessary to indicate whether the value is “true” (required). You can use aria-required=”false” for inputs where a response is not required, however this is not essential since this is the assumed default value if aria-required is not present. For example:

 <label for="gname">Given Name:</label>
 <input type="text" name="givenname" id="gname" 
 aria-required="false">
 <label for="fname">Family Name:</label>
 <input type="text" name="familyname" id="fname" 
 aria-required="true">

At this time, screen reader support for aria-required with different browsers appears to be slightly better than is the case for HTML5 required, but it is not supported by current versions of WindowEyes. It should be noted however, with aria-required none of the browsers provide a visual indication when a required form field is not completed.

HTML5 and ARIA

Since the support provided by browsers and/or screen readers for the HTML5 required attribute and the aria-required attribute varies, both attributes are now sometimes used to indicate a mandatory input. For example:

 <label for="suburb">Suburb:</label>
 <input type="text" name="suburb" id="suburb" 
  aria-required="true" required>

For more information about using ARIA and HTML5 to indicate required form fields: John Foliot – Accessible HTML5 Forms – Required Inputs http://john.foliot.ca/required-inputs/

What is the best way to indicate a mandatory field?

In my opinion, the HTML5 and ARIA attributes alone shouldn’t be relied upon to indicate required form fields, since these fields will not be immediately identifiable visually. As a result, when considering the optimal approach for a particular site, it will usually come down to choosing one of the three ways mentioned earlier:

  • My preferred technique is to include the word ‘required’ in the label element to indicate mandatory form fields since the required fields will be clearly identified to all. Also the technique is robust in that it is well supported by browsers and assistive technologies. However, I recognise that corporate, design and development constraints will mean that including the word ‘required’ in the label element will not always be possible.
  • In some organisations, the high-level of control over branding issues extends to bespoke graphic icons for things like information and required form fields. In these cases, a graphic is completely accessible so long as it is contained within the label element and has an appropriate alt attribute.
  • The third alternative is to include a keyboard asterisk (star) in the label element. In my experience, when most screen reader users hear the word ‘star’ in association with a form input they automatically assume it means that a response is required. There is however, one major caveat: Some screen readers (or screen reader versions) do not report the keyboard star by default. While this function can be turned on by changing the verbosity settings, it may be wrong to assume all screen reader users will know how to do this.

When one of the techniques described above is used, it is sometimes supplemented with the HTML5 required attribute and/or the aria-required attribute. However, this should be done judiciously to avoid overloading screen reader users with unnecessary repetition of information.

This section of code from a personal details form includes different ways of identifying required form fields (NB: the word ‘mandatory’ rather than ‘required’ has been used so that they can be easily distinguished from the programmatic identification of required fields when tested with screen readers).

 <label for="fname">Family Name *:</label>
 <input type="text" name="familyname" id="fname" 
 aria-required="true">
 <label for="gname">Given Name:</label>
 <input type="text" name="givenname" id="gname" 
 aria-required="false">
 <label for="street">Street (Mandatory):</label>
 <input type="text" name="street" id="street" 
 required>
 <label class="label" for="suburb">Suburb (Mandatory):
 </label> 
 <input type="text" name="suburb" id="suburb" 
 aria-required="true" required>

How these form fields are reported by the NVDA 2012.3 screen reader with Firefox 20 are demonstrated in the following video:

Personal details form with required input fields

Transcript of personal details form with required fields video

The following table provides a brief outline of how the four personal details form fields in the video are presented by different screen readers.

Form input field JAWS 13 WindowEyes 8.1 NVDA 2012.3 VoiceOver
Family name(aria-required) Star reported. Also identified with aria-required Star reported. Star not reported. Identified with aria-required Star reported.
Given name (not required) Label text only voiced Label text only voiced Label text only voiced Label text only voiced
Street(HTML5 required) Word mandatory reported. HTML5 required attribute is reported with FF but not with IE.
NB: See note below about the HTML5 ‘invalid entry’ comment.		 Word mandatory reported. HTML 5 required attribute is also reported with FF but not with IE.
NB: See note below about the HTML5 ‘invalid entry’ comment.		 Word mandatory reported. HTML5 required attribute is reported with FF but not with IE.
NB: See note below about the HTML5 ‘invalid entry’ comment.		 Word mandatory reported. HTML 5 required attribute is also reported.
Suburb(aria-required and HTML5 required) Word mandatory reported. And aria-required reported (i.e. both the words ‘mandatory’ and ‘required’ are voiced).
NB: See note below about the HTML5 ‘invalid entry’ comment.		 Word mandatory reported. HTML 5 required attribute is also reported with FF.
NB:See note below about the HTML5 ‘invalid entry’ comment.		 Word mandatory reported. And aria-required reported (i.e. both the words ‘mandatory’ and ‘required’ are voiced).
NB: See note below about the HTML5 ‘invalid entry’ comment.		 Word mandatory reported. HTML 5 required attribute is also reported. 

NOTE:  When using JAWS 13/14, NVDA 2012.3 and WindowsEyes 8.1 with Firefox 20 (and maybe some other browsers) the HTML5 ‘invalid entry’ message is presented for each required form field when arrowing through the form in browse mode or tabbing from input to input in forms mode. Since this warning appears before an entry has been made it could be potentially confusing for some users.

* When discussing this with Gez Lemon he told me that it used to be possible to get around this problem with Firefox using aria-invalid and initially setting it to false (aria-invalid=”false”). Then, when a user skips over a HTML5 required field without making an entry, Javascript is used to switch aira-invalid to “true”. However, it appears that with recent versions of Firefox it appears that this technique does not work. Also, in some circumstances, JAWS 13 continues to present the ‘invalid entry’ message even after the input has been filled in appropriately. Many thanks to Gez and Grant Focas for helping me understand this problem and trying to finding as solution. When we find a satisfactory solution, I will update this article with a new video demonstrating it.

At this time, I feel that including HTML5 required and/or aria-required attributes is probably only necessary when using the keyboard asterisk as the visible indication of required form fields. The HTML5 required or aria-required attributes should be used with care to avoid unnecessary duplication of information or confusion for screen reader users. However, these attributes maybe useful when it comes to error detection and correction, as discussed in the next article in this series.

Providing extra information

Sometimes it is necessary to provide some additional information to help ensure a form field is completed correctly. For example, a date can be written in many ways, and when the form requires a particular format this should be indicated (e.g. dd/mm/yyyy).

Wherever possible, additional information about things like the required format should be included in the label element. However, often this does not fit in with the preferred visual design for the form.

Here are three alternative ways to include information about the format needed for entering a date. The visual appearance of all three will be exactly the same with the date format example after the input field:

a. Included in the label element

In the following section of code, the label element includes the actual label, the input field and the date format information. The label for attribute is used to associate the label with the input, which has a matching id attribute.

 <label for="regdate">Registration date:
 <input type="text" name="course" id="regdate">
 (dd/mm/yyyy)
 </label>

b. Re-positioned with CSS

In the following HTML code for the start date, the date format is included as part of the label element that is explicitly associated with the input. Although the date format is before the input in the source code, the section of CSS code is used to position it visually after the input.

CSS:

.input
{
 float: left;
 width: 12em;
 margin: 0 1em 0 0;
 padding: .3em .5em;
 border: 1px solid #666;
 background: #eee;
}
.format
{
 position: absolute;
 width: 6em;
 left: 24em;
}

HTML:

 <div>
 <label for="startdate">Start date:
 <span>(dd/mm/yyyy)</span>
 </label>
 <input type="text" name="course" id="startdate" />
 </div>

c. Using aria-describedby

The format information for the end date is associated with the input through the use of aria-describedby. The format information is in a span with id=”dateformat”, that matches the aria-describedby value in the input.

 <label for="enddate">End date:</label>
 <input type="text" name="enddate" id="enddate" 
 aria-describedby="dateformat">
 <span id="dateformat">(dd/mm/yyyy)</span>

One really nice feature of aria-describedby is the ability to associate more than one piece of extra information with an input. The different sections of content are identified with different ‘id’ attributes. These ids are then presented as space-separated values for the input aria-describedby attribute. For example:

 <label for="birthdate">Date of Birth:</label>
 <input type="text" name="birthdate" id="birthdate"  
 aria-describedby="dateformat agerule">
 <span id="dateformat">(dd/mm/yyyy)</span> 
 <span id="agerule"> Note: If under the age of 18 permission  
 of parent or guardian will be required</span>

The extra information to be associated with an input using aria-describedby can be anywhere in the document, and in some cases, may only be included when necessary following an earlier response.

Methods compared

The following table provides a brief outline of how the three form fields with the different ways of providing the date formatting information are presented by different screen readers.

Form field input JAWS 13 WindowEyes 8.1 NVDA 2012.3 VoiceOver
Registration date(implicit label method) Browse mode: Date information is available in browse mode, but need to arrow to it.
Forms mode: date information is clear.		 Browse mode: Date information is available in browse mode, but need to arrow to it.
Forms mode: date information is clear.		 Browse mode: Date information is available with IE and FF, but requires little more arrowing with FF.
Forms mode: Information is clear with both IE and FF.		 Date information available without arrowing to it.
Start date(re-positioning method) Browse mode: Date information read out in association with the label.
Forms mode: Date information is clear.		 Browse mode: Date information read out in association with the label.<br >Forms mode: Date information is clear. Browse mode: Date information is available with IE and FF, but requires little more arrowing with FF.
Forms mode: Information is clear with both IE and FF.		 Date information available without arrowing to it.
End date(aria-describedby method) Browse mode: Date information is available in browse mode, but need to arrow to it.
Forms mode: Date information is presented (but not as clear). And the standard words, ‘type in text’ not voiced.		 Browse mode: Date information is available in browse mode, but need to arrow to it.
Forms mode: Date information is not presented.		 Browse mode: Date information is available with IE and FF, but requires little more arrowing with FF.
Forms mode: Information is clear with both IE and FF.		 Date information available if you wait several seconds after reaching the input fields or by arrowing to find it.

How these are form fields are reported by the NVDA 2012.3 screen reader with Firefox 20 are demonstrated in the following video:

Transcript of providing extra information video

 

More information

Gez Lemon – Accessible browser validation in HTML 5 http://juicystudio.com/article/accessible_browser_validation_html5.php

John Foliot – Accessible HTML5 Forms – Required Inputs http://john.foliot.ca/required-inputs/

Ted Drake – How to define required input fields with ARIA and HTML 5 http://developer.yahoo.com/blogs/ydn/define-required-inputs-aria-html5-53573.html

W3C – WAI-ARIA Authoring Practices http://www.w3.org/WAI/PF/aria-practices/

WCAG 2 ARIA technique – Using the Describedby Property http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html

Steve Faulkner – HTML5 Accessibility Chops: Notes on using ARIA http://blog.paciellogroup.com/2012/06/html5-accessibility-chops-using-aria-notes/

Marcos accessibility blog – Easy ARIA Tips 2: aria-labelledby and aria-describedby http://www.marcozehe.de/2008/03/23/easy-aria-tip-2-aria-labelledby-and-aria-describedby/Karl

Karl Groves – Accessible form labeling & Instructions http://www.karlgroves.com/2011/10/10/accessible-form-labeling-instructions/

 Acknowledgements and thanks

This series of articles builds on the work of many accessibility advocates over the years. For their inspiration, knowledge, talent and help, I would particularly like to thank: Andrew Downie, Russ Weakley, Steve Faulkner, Hans Hillen, Gez Lemon, John Foliot, Jason Kiss and Adam Zerner.

 Transcripts

Video 1: Indicating required form inputs

ROGER: Okay here we have a form with four inputs, and three are required or mandatory. Family name is required and this is indicated with the keyboard star, or asterisk, and aria-required equals true. Given name is not required and it uses aria-required equals false. The street name is required and this is indicated with the word mandatory and also the HTML five required attribute. And, the suburb is required indicated with the word mandatory and the HTML five attribute required as well as aria-required equals true. Let’s see how this reads with NVDA and I’m using firefox.

SCREEN READER: Heading level one, identifying required inputs. Family name edit required has autocomplete.  Given name edit has autocomplete. Street mandatory edit required has autocomplete invalid entry. Suburb mandatory edit required autocomplete invalid entry. Button submit. Heading level two, end of form.

ROGER: I’m now going to go back to the top of form using shift-H.

SCREEN READER: Identifying required inputs heading level one.

ROGER: This time I will arrow through the form.

SCREEN READER: Family name edit required has auto complete.

ROGER: you might have noticed the keyboard star was not reported, but the aria-required attributes indicated that it was a required field.

SCREEN READER: Given name edit has autocomplete.

ROGER: No mention of it being required.

SCREEN READER: Street mandatory edit required has autocomplete include entry in this case the word mandatory is read with the label street and also that required attribute is reported as required, and we get this strange mention of invalid entry.

SCREEN READER: Suburb mandatory edit required has autocomplete invalid entry.

ROGER: In this case the word mandatory is read with the label suburb and we hear that the input is required and also we get the invalid entry comment.

SCREEN READER: Button submit, heading level 2 end of form.

ROGER: Let’s go back to the top of form.

SCREEN READER: Identifying required inputs, heading level one.

ROGER: I am now going to tab through the form and fill it in.

SCREEN READER: Family name edit required has autocomplete, blank. T-O-M. Given name edit has autocomplete blank. J-O-N-E-S. Street mandatory edit invalid entry required has autocomlete, blank.

ROGER: So we know it’s required from the word mandatory we also know it’s required from the input telling us it’s mandatory but it is also saying invalid entry.

SCREEN READER: C-O-O-K R-O-A-D. Suburb mandatory edit invalid entry required has autocomplete, blank.

ROGER: Much the same as with street, the word mandatory is read with the suburb and input tells us required and we’re told we’re told it’s an invalid entry.

SCREEN READER: N-E-W-T-O-W-N.

ROGER: I’ll tab back to the street and see what happens.

SCREEN READER: Street mandatory edit required autocomplete, selected Cook Road.

ROGER: Okay, so now it makes it clear that it is Cook Road and we go down.

SCREEN READER: Suburb mandatory edit required has autocomplete, selected Newtown.

ROGER: So this form is reasonably easy to fill in. It’s a little confusing when you read through the form or arrow through the form having these fields of identified as being invalid. But, when you fill them in that invalid entry comment disappears.

Video 2: Providing extra information for filling in form inputs

ROGER: We have here a form with three inputs for entering the date, and the required format for the date is indicated after each input. The way this format information is associated with the inputs is different in each case. I’m going to read down this page with NVDA using Firefox.

SCREEN READER: Heading level one, providing extra information for form inputs. Registration date, edit has autocomplete, dd slash mm slash yyyy. Start date, dd slash mm slash yyyy, edit has autocomplete. End date, edit has autocomplete, dd slash mm slash yyyy. Button submit. Heading level two, end of form.

ROGER: In each case, the label and the information relating to the format was read with the inputs. Let’s go back to the top by Shift+H.

SCREEN READER: Providing extra information for form inputs, heading level one.

ROGER: I’m now going to arrow through the form.

SCREEN READER: Registration date, edit has autocomplete, dd slash mm slash yyyy. Start date, dd slash mm slash yyyy, edit has autocomplete. End date, edit has autocomplete, dd slash mm slash yyyy.

ROGER: Once again the label and the date format information was read out although there’s some slight differences in the order the information is presented. Let’s go back to the top.

SCREEN READER: providing extra information for form inputs, heading level one.

ROGER: In this case I’m going to tab through the form as though I was filling it in.

SCREEN READER: Registration date, dd slash mm slash yyyy, edit has autocomplete. Blank. Start date, dd slash mm slash yyyy, edit has autocomplete. Blank. End date, edit has autocomplete, dd slash mm slash yyyy. Blank.

ROGER: And, once again the label and the required format was read out. So, effectively, in each case, all the information you need to fill in this form was presented.

Accessible Forms 1: Labels and identification

by
, ,

The first in this series of articles about improving the accessibility of web page forms:

Nearly every website contains at least one form, and the content of some sites is primarily forms. These articles aim to provide information that will help you make forms that comply with WCAG 2.0, while also recognising the practicalities of making usable forms for today’s web.

This article will look at ways to identify and group form controls (e.g. input type=”text”) with:

  • Explicit associated labels
  • Implicit labels
  • Title attribute
  • Fieldset and legend

This article will also briefly consider the use of WAI-ARIA for labelling forms and some of the new HTML5 input types.

NB: The sample forms were tested using JAWS 13, WindowEyes 8.1, and NVDA 2012.3 with recent versions of Internet Explorer (IE) and Firefox (FF). Also tested with Apple VoiceOver using Safari 6.

Identifying form controls

These commonly used form controls, input (various types), textarea and select, are generally identified with the HTML <label> element. In these articles I will use the term “input” to identify these different controls unless stated otherwise.

(NB: Some controls, such as button or image, do not need labels because they can be identified with ‘accessible names’ provided by an attribute of the element, or the content itself.)

Visible labels that are easy to identify benefit all web users who are able to see them. Screen reader users also need to be able to identify and use form inputs. Windows screen readers (e.g. JAWS, Window Eyes and NVDA) allow users to interact with a web page in two main ways.

  • With the virtual buffer on (‘virtual cursor’ or ‘browse’ mode), the user can read the page and quickly locate a form and scan its content. However they are unable to enter content into a text input field in this mode.
  • With the virtual buffer off (‘forms’  or ‘browse off’ mode), the user is able to enter content into form fields, but can only move easily between objects on the page that can accept focus (e.g. form inputs and links). As a result, the user needs to switch out of ‘forms’ mode if they wish to read any headings or text that might be between form fields.

Most modern screen readers will automatically switch to ‘forms’ mode when focus is shifted to a form element, and back to ‘virtual cursor’ mode when focus shift to non-form elements. The keyboard can also be used to manually change modes.

An inability to identify form inputs can result in a failure to comply with several WCAG 2.0 Success Criteria:

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

4.1.2 Name, Role, Value: For all user user-interface components (including but not limited to: form elements, links etc), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

The following video shows how the NVDA screen reader (with Firefox 20) presents a simple form containing three inputs, which are identified using explicit or implicit labels and the title attribute.

Three inputs form

Three inputs form video transcript

NB: Not all screen readers or screen reader-browser combinations will behave in exactly the same way as NVDA does in this video.

When it comes to identifying form inputs WCAG 2.0 offers two “Sufficient Techniques”:

 Using label elements to associate text labels with form controls (Sufficient Technique H44)

Using the title attribute to identify form controls when the label element cannot be used (Sufficient Technique H65)

Both of these techniques will allow an input name to be programmatically determined, for example by a screen reader. And, using the label element (Technique H44) has the added benefit of increasing the size of the clickable area, which will make it easier for people with poor fine-motor skills to use.

It should be noted however, to fully comply with Success Criteria 2.4.6 and 3.3.2 the label must be visible since this will assist all web users and not just those who rely on a screen reader.

Explicit Form labels

With most HTML forms, the aim or purpose of each input should be identified with an ‘explicit’ text label that is presented using the HTML label element with a “for” attribute that has the same value as the matching input “id” attribute.  For example: 

<label for="fullname">Name: </label>
<input type="text" name="fullname" id="fullname">

The label “for” and the input “id” attributes can be used with any of the form fields, for example text inputs, text area, select menus, checkboxes and radio buttons, but the “id” attribute for each element in a document must be unique.

The use of explicit labels to enhance accessibility is well supported by screen readers and browsers, so wherever possible explicit labels should be used to identify form inputs.

Implicit labels

Implicit labels do not contain a label “for” attribute with a matching input “id” attribute. In this case, both the label text and the form input are inside the label element. For example: 

<label>
	Country:<input type="text" name="country">
</label>

The specifications for HTML (including HTML5) and XHTML allow the use of implicit labels, and their use is not specifically excluded in WCAG 2.0.

The use of implicit labels to identify an input type for commonly used form controls was not very well supported by some earlier versions of screen readers (pre 2007). And, support for the select form control is still a little patchy in some circumstances. We have tested the following example with a number of screen readers and the results when using NVDA are shown below. 

<label>
	Country:<input type="text" name="country">
</label>
<label>
	Region:
	<select>
		<option value="1" selected>Please choose a region</option>
		<option value="2">Coastal</option>
		<option value="3">Forest</option>
		<option value="4">Grasslands</option>
		<option value="5">Mountains</option>
	</select>
</label>

The following video shows how the NVDA screen reader (with Firefox 20) presents this form with two implicit labels.

Implicit labels form

Two implicit labels form video transcript

Below is a brief outline of the results of testing this form with different screen reader/browser combinations:

JAWS 13 WindowEyes 8.1 NVDA 2012.3 VoiceOver
Browse Mode:With IE and FF, the labels for both the input and select form controls are read when tabbing from field to field.Forms Mode: With both IE and FF, the labels appropriately identify both types of inputs when they receive focus. Browse mode:With IE and FF, the labels for both the input and select form controls are not read when tabbing to the controls.Forms mode:The labels are read when focus goes to each control with both IE and FF.However, in ‘forms’ mode with IE, there appears to be a bug that causes the label “Country” to be read before the “Region” options in the select control. Browse and Forms Modes: Reads the label for both the input and select fields with IE and FF.  Reads select options well in both modes. Reads label for both input and select field when both interacting with the HTML content and the input and select elements.

Title attribute

Sometimes it is not possible to provide a form label. The most obvious and common examples of this are the form inputs for “search” on many sites that do not have a visible label. Some developers do provide a label in this situation, but use CSS to remove it from the visual presentation of the page content.

In cases where it is not possible to provide a label, WCAG 2 (Technique H65) permits the use of the “title” attribute for form inputs and still comply at Level A.

Form fields inside a data table such as those used for order forms maybe another case where use of the “title” attribute is the most practical approach. For example, the following table contains a Kitchen Safety order form with input and select elements that use “title” attributes to indicate the number of items ordered:

Screen shot of order form - link to form provided in text

Extract of page code for section of Kitchen Safety order form: 

<tr>
	<th>
		FS2
	</th>
	<td>
		Slippery when wet floor sign
	</td>
	<td>
		<input type="text" title="enter number of slippery when wet signs you want" value="">
	</td>
</tr>
<tr>
	<th>
		P12
	</th>
	<td>
		A3 Food preparation hygiene poster
	</td>
	<td>
		<select title="Choose number of food preparation posters to order">
			<option value="0" selected>0</option>
			<option value="1" selected>1</option>
			<option value="2" selected>2</option>
		</select">
	</td>
</tr>
... code continues ...

Full Kitchen Safety form

The following video shows how the NVDA screen reader presents the Kitchen Safety Order form with two fields identified with “title” attributes.

Kitchen Safety Order form video transcript

Below is a brief outline of the results of testing the Kitchen Safety order form with different screen readers:

JAWS 13 WindowEyes 8.1 NVDA 2012.3 VoiceOver
Browse and Forms modes:Text input and select are both identified when using either IE or FF.Also reads column and row headings. Browse and Forms modes:text input and select are both identified when using either IE or FF.Doesn’t read column headings by default but easy to turn on if required. Browse mode:Doesn’t read the title attribute to identify the text input or select with either IE or FF.Forms mode: text input and select are both identified when using either IE or FF. Identifies both inputs adequately.Reads column headings.  Pauses for some seconds before reading the prompt in both the input and select form controls, but does read them.

Grouping with Fieldset and Legend

A well organised form with related inputs or requests logically grouped together is easier for everyone to use and is particularly important for people with cognitive disabilities or learning difficulties.

Similar form items are often grouped together visually by the use of dividing lines, boxes or changes in background colour. However, this is not much use to someone who is unable to perceive this visual presentation.

The HTML elements fieldset and legend allow forms with different areas of interest to be organised in a logical way that can be determined programmatically.

H71: Providing a description for groups of form controls using fieldset and legend elements (Sufficient Technique H71)

The following code excerpt provides a simple example of fieldset and legend: 

<fieldset>
	<legend>Personal details</legend>
	<label for="first-name">First name</label>
	<input name="first-name" id="first-name" type="text">
	<label for="family-name">Family name</label>
	<input name="family-name" id="family-name" type="text">
	<label for="email">Email</label>
	<input name="email" id="email" type="text">
</fieldset>

Another good use of fieldset and legend is with radio buttons or checkboxes where it is often difficult to provide a context for the different options in a way that is associated with them. Legend is an effective way of providing a programmatic context, for example: 

<fieldset>
	<legend>Preferred contact method</legend>
	<input name="contact-method" id="phone" type="radio">
	<label for="phone">Telephone</label>
	<input name="contact-method" id="email" type="radio">
	<label for="email">Email</label>
	<input name="contact-method" id="snail" type="radio">
	<label for="snail">Registered post</label>
</fieldset>

When JAWS (with Internet Explorer 9) is used to access a form that uses fieldset and legend and contains explicitly associated labels (as shown above), it will voice the ‘legend’ text before every ‘label for’ text within the fieldset when in forms mode.

With other screen readers the process is a little different. For example, WindowEyes simply announces the beginning and end of each fieldset if ‘Speak fieldsets’ is turned on, which it is not by default. VoiceOver behaves similarly to JAWS, but announces the ‘legend’ text after the ‘label for’ text.

NB: The fieldset element should only be used when there are a number of related form controls that need to be grouped together. And, when the fieldset element is used, the first element inside the fieldset must be a legend.

Care should be taken when nesting fieldsets to avoid making a form too complicated and to ensure the aim of the nesting is correctly presented by screen readers. Some screen readers, or early versions of screen readers, can have problems with nested fieldsets.

ARIA Label and Labelledby

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Application) provides several other possible ways of identifying form fields (as well as other page components). However, in general ARIA is not as well supported as the other techniques discussed in this article, and should not be used to identify form inputs when a native HTML alternative is available.

aria-label

“aria-label” is an attribute that can be used with an input when it is not possible to include a HTML label element. For example: 

<input type="text" aria-label="site search" id="search">

NB: “aria-label” must not be used when there is a visible label.

aria-labelledby

“aria-labelledby” allows more than one piece of information to be associated with a form field. The different pieces are identified with ‘id’ attributes, and these are presented as space-separated values for the input “aria-labelledby” attribute. For example in the attached example of a form using labelledby, the words “full name” and the information about using passport details are both associated with the text input.

“aria-labelledby” also allows one piece of information to be associated with multiple form fields through repeated use of the “aria-labelledby” attribute. For example in the attached example of a form, the text “Date of birth” is associated with the three select inputs for day, month and year.

Web page with example of a simple form using labelledby.

The results of testing the labelledby form with different screen readers are briefly outlined below:

JAWS 13 WindowEyes 8.1 NVDA 2012.3 VoiceOver
Browse mode:With IE and FF, reads the name text and passport note text when tabbing to text input, but not read when arrowing through the form.Similar results for the ‘date of birth’ the select menus for day, month and year.Forms mode with IE:Reads name and passport note when tabbing to the text input. But, does not use “date of birth” to identify the day, month and year select controls.Forms mode with FF: The name and passport text are associated with the text input. And, the ‘date of birth’ text is associated with the three select controls. Browse mode:With IE, reads only full name for the text input field. With FF also reads passport note.Reads ‘date of birth’” with the three select menus with both IE and FF.Forms mode with IE and FF: Reads name and passport note when tabbing to the text input. And, uses ‘date of birth” to identify the three select controls for day, month and year. Browse mode:With both IE and FF the labelledby  information is not explicitly associated with either the name or date of birth controls, but is available by arrowing.Forms mode: With IE uses ‘full name’ but not the passport note to identify the input. With FF ‘full name’ and passport note are both reported.For ‘date of birth’ section, these words are used to identify the three select menus (day, month and year) with both IE and FF. Reads ‘full name’ plus the passport information when encountering the edit fields. Reads ‘date of birth’ when encountering each select (combo) menu (presented as “popup button” by Voiceover)

Three important notes about aria-labelledby:

  1. “aria-labelledby” should not be used with form inputs when the input also has an explicitly associated label. This will result in some screen readers only reading the “labelledby” information and ignoring the label.
  2. “aria-labelledby” should not be used when the same result can be achieved with native HTML elements
  3. “aria-describedby” is a better way of providing additional information that may be required to complete a form field.

 

New HTLM5 input types

Before HTML5 the range of input types was limited, but HTML5 has introduced 13 new input types for use with forms. A description of all the new input types is available from the HTML5 Doctor, HTML5 Forms Input Types. I am going to briefly paraphrase the HTML5 Doctor description of four that are likely to be increasingly used in the future. (Sample form containing these examples and information about how well they are supported follow the descriptions).

Email

On the screen, the email input type looks no different to the standard text type. However, when combined with the HTML5 required attribute, there is the potential for browsers to determine whether or not the information entered contains the basic features of an email address such as the @ character.

Tel

Since phone numbers differ around the world, it is difficult to guarantee any specific way of entering the number, except for allowing only numbers and perhaps a + symbol to be entered. It’s possible you can validate specific phone numbers (if you can guarantee the format) using client-side validation.

Number

The number input type aims to make entering numbers easier by providing a ‘spinbox’ control that is operated by using the arrow icons to move up and down the number options. With the additional attributes min, max, and step, the minimum, maximum, and starting values as well as step value of the spinbox control can be set.

Date

The date input type generates a date picker for selecting dates without requiring the use of JavaScript. In addition to the standard date input, there are inputs for selecting a week, month, time, and date and time. With the min and max attributes you can set the date choice to a specific date range. (It should be noted, the date format can’t be changes, and with some browsers you have to use the date picker since the date can’t be typed directly into the input.)

The following code excerpt includes the four new HTML5 input types. 

<label for="email">Email</label>
<input type="email" name="email" id="email" required>

<label for="tel">Telephone number</label>
<input type="tel" name="tel" id="tel" required>

<label for="shoe">Shoe size</label>
<input type="number" id="shoe" min="5" max="18" step="0.5" value="9" name="shoe-size">

<label for="startdate">Start date</label>
<input type="date" id="startdate" name="startdate" min="2013-01-01" max="2014-01-01">

At this stage, browser support for the new HTML5 input types is variable. The form excerpt above was tested with four browsers with the following results:

  • The email and tel inputs behaved much like standard text inputs with the four browsers.
  • The number input type (shoe size) and the date input type (start date) could be used with Chrome 26. The actual date picker calendar could only be obtained with the mouse, but without a mouse it was relatively easy to enter a date with the keyboard arrow keys.
  • The number and date inputs did not work at all with Internet Explorer 9 or Firefox 20.
  • With Opera 12, there was no number type ‘spinbox’, and the date only worked partially and was effectively unusable.

The Wufoo Current State of HTML5 charts the level of browser support for HTML5 input types, attributes and elements.

The following table provides a brief description of how well the example HTML5 form input types on this page are supported by three browser/screen reader combinations:

JAWS 14 with I.E. 10 NVDA 2012.3 with Chrome 26 VoiceOver with Safari 6
Email Can type in email address Can type in email address Can type in email address
Tel Can type in number Can type in number Can type in number
Shoe size ‘Spinbox’ not identified, but able to type in number (or characters) Can use ‘spinbox’ to change size, but the word ‘blank’ voiced for all sizes ‘Spinbox’ adjusted to make on size change with the arrow key, but no more. Also, reporting of size did not appear to be correct or logical.
Date No calendar or other way of changing date, But could type in date. Can use arrow keys to change day, month and year values, which are reported when changed. No calendar or other way of changing date, But could type in date.

Given the lack of adequate browser and assistive technology support for these new HTML5 input types, it would be unwise to rely on them solely when it comes to accessibility. However, one big advantage of using them is the level of support that appears to be provided by mobile devices, in particular the iPhone (see HTML5 Forms Input Types for more information).

For more information:

WebAIM – Creating accessible forms http://webaim.org/techniques/forms/

Steve Faulkner – HTML5 Accessibility Chops: Form control labelling http://blog.paciellogroup.com/2011/07/html5-accessibility-chops-form-control-labeling/

Marcos accessibility blog – Easy ARIA Tips 2: aria-labelledby and aria-describedby http://www.marcozehe.de/2008/03/23/easy-aria-tip-2-aria-labelledby-and-aria-describedby/Karl

Karl Groves – Accessible form labeling & Instructions – http://www.karlgroves.com/2011/10/10/accessible-form-labeling-instructions/

Jason Kiss – Title attributes as form control labels http://www.accessibleculture.org/articles/2010/10/title-attributes-as-form-control-labels/

For general information about the design and usability of forms see various articles written by Jessica Enders from Formulate http://formulate.com.au/articles/

Acknowledgements and thanks

This series of articles builds on the work of many accessibility advocates over the years. For their inspiration, knowledge, talent and help, I would particularly like to thank: Andrew Downie, Russ Weakley, Steve Faulkner, Hans Hillen, Gez Lemon, John Foliot, Jason Kiss, and Adam Zerner.

Transcripts

Video 1: Three form inputs

ROGER: Here we have a simple form with three inputs the first has the label which is explicitly associated, the second has an implicit label, and the third has no label element at all, but is identified with the title attribute. I’m using firefox twenty and I am using NVDA. Let’s see how it reads:

SCREEN READER: Heading level one, three form inputs forms one example. Explicit label edit has auto-complete. Implicit label edit has auto-complete. No label element edit has auto-complete. Button submit. Heading level two, next heading.

ROGER: I’ now going to go back up to the top by pressing shift H.

S.R: Three forming inputs forms one example, heading level one.

ROGER: This time I’m just going to arrow through the form.

S.R: Explicit label edit has auto-complete. Implicit label edit has auto-complete. No label element edit has auto-complete. Button submit. Heading level 2, next heading.

ROGER: I’m going to go back up to the top now.

S.R: Three form inputs forms one example, heading level one.

ROGER: This time I am going to tab through the form as though I was filling it in.

S.R: Explicit label edit has auto-complete, blank. C-A-T

ROGER: I’m just writing odd words.

S.R: Implicit label, edit has auto-complete, blank. D-O-G. No label element, but identified with title, edit has auto-complete, blank.

ROGER: That time you will have noticed that it read the title attribute.

S.R: B-I-R-D

ROGER: So all the inputs in this form can be identified when you’re actually in the process of filling in the form.

Video 2: Implicit form labels

ROGER: This form has a text input and a select menu or combo. Both are identified with implicit labels. Let’s see how it goes with NVDA and Firefox twenty.

SCREEN READER: Heading level one implicit labels with text input and select elements forms one example. Country, edit has auto complete.  Region, combo box collapsed please choose a region. Heading level two page continues.

ROGER: Okay I’m going to go back to top by pressing shift H.

S.R: Implicit labels with text input and select elements, forms one example. Heading level one.

ROGER: This time I’m going to arrow through it.

S.R: Country edit has auto complete. Region combo box collapsed please choose a region.

ROGER: Now I’m going to get back to top again.

S.R: Implicit labels with text input and select elements forms one example. Heading level one.

ROGER: This time I’m going to tab through the form as though I was filling it in.

S.R: Country edit has auto complete, blank. A-U-S-T-R-A-L-I-A. Region combo box, please choose a region collapsed.

ROGER: I go through the regions with the arrow key.

S.R: Coastal, forest, grasslands, mountains, grasslands, forest.

ROGER: Able to go back up and down the choices. And as you can see the text input was successfully identified by the implicit label country, and the combo, or select menu, was successfully identified by the implicit label region.

Video 3: Identifying with title attribute

ROGER: This order form uses input title attributes to help identify the number of items to be ordered. I’m going to read it with NVDA and firefox

SCREEN READER: Heading level one order form, Forms one example. Table with three rows and three columns. Kitchen safety orders, kitchen safety orders.

Row one, column one item code, column two item description, column three order quantity.

Row two item code column one FS2. Item description column two slippery when wet sign. Order quantity column three edit has auto complete.

Row three item code column one P12. Item description column two Food Preparation Poster order quanity column three combo box collapsed zero. Out of table button submit.

ROGER: I’m going to go back to top of form using shift H.

S.R: Order form, forms one example. Heading level one.

ROGER: This time I will arrow through the form.

S.R: Table with three rows and three columns. Kitchen safety orders, Kitchen safety orders.

Row one column one item code column two item description column three order quantity.

Row two item code column one FS2. Item description column two slippery when wet sign. Order quantity column three edit has auto complete.

Row three item code column one P12. Item description column two food preparation poster. Order quantity column three combo box collapse zero.

ROGER: So when reading this form or arrowing through the form it is reasonably easy to work out how many items you’re going to be ordering. Let’s go back to the top

S.R: Out of table. Order form, forms one example. Heading level one.

ROGER: This time I’m going to tab through the form and fill it in.

S.R: FS2 row two, order quantity column three. Enter the number of slippery when wet signs you want, edit has auto complete blank.

ROGER: Let say we order five signs.

S.R: Five.

S.R: P12 row three, choose number of food preparation posters to order combo box zero collapse.

ROGER: I wonder how many different order options I’ve got?

S.R: One, five, twenty, fifty.

ROGER: I think twenty. So when filling in the form it is easy to know how many items you are ordering with both the input field and the select combo.

Accessibility: More than WCAG compliance – CSUN2013 Talk

by
, , ,

On 27 February 2013, I gave the presentation “Accessibility: More than WCAG compliance” at the 28th Annual International Technology and Persons with Disabilities Conference (CSUN 2013).

Many countries now use the Web Content Accessibility Guidelines, Version 2 (WCAG 2) as the benchmark for determining the accessibility of web content, and the regulators in these countries require government agencies and corporations to comply with the WCAG 2 Success Criteria. Since the release of WCAG 2, there has been considerable debate about how to determine the accessibility of websites: either using a checklist to determine the level of compliance/conformance with the specific Success Criteria; or, undertake some form of user testing by people who have different disabilities and/or who rely on different assistive technologies. Both approaches have their strengths and limitations, and neither can provide a reliable declaration about the accessibility of a site on its own.

Unfortunately web content accessibility is being increasingly viewed solely from the perspective of how well a site complies with WCAG 2 rather than how well people with disabilities can access the content.

During this session, I outline a new Accessibility Priority Tool (APT) that was developed in early 2013. This tool (Excel Worksheet) aims to help organizations and developers identify likely access barriers to web content, and prioritise their efforts to correct them.

I would like to thank Andrew Downie for his help in preparing the APT Excel worksheet, also the many people who attended this session for their interest, comments and questions.

(NB: In this Accessibility Priority Tool Excel worksheet, Column I is hidden. This column is used to calculate the worksheet ‘Access Barrier Advice’ for each item that is presented in Column F

The slides from the presentation and the speaker’s notes follow:

Speakers notes

Slide 1

For those who aren’t familiar with the Web Content Accessibility Guidelines, when I use the acronym WCAG during this talk this what I am referring to.

Slide 2

On the screen we have a heading, “Tale of two sites”, followed by the opening of Charles Dickens book with a similar tile:

“It’s the best of time, it’s the worst of time. We have everything before use, we have nothing before us.”

Okay, say we have two sites:

  • One with a few images in the content area that are missing alt attributes
  • The other, where the developer has gone for the subtle look, so contrast ratio for all the text is 3.2:1

For most of us neither of these sites is likely to present any accessibility problems.

  • So which is the least accessible?
  • Which is the most likely to cause users problems?
  • Or to continue to take liberties with Charles Dickens’s Tale of Two Cities, which developers should go to the guillotine and which to the Bastille?

Slide 3

Now this is the people’s court, you have to choose.

Bear in mind however, that under WCAG 2.0 failure to include alternatives for non-text content is a Level A issue – an absolute no-no, but only a few alts are missing.  On the other hand, colour contrast is at Level AA and a contrast ratio of 3.2:1 would be fine for text that is considered “large”, but all the text on the site is too low.

Okay, hands up those who want to give the thumbs down, to mix historical metaphors, to the missing alts.

And now, those who feel our subtle colour scheme should go to the chopping block.

And, the rest of you are just going to sit there knitting, watching the action.

Slide 4

Now, let’s consider our two examples from the perspective of some potential site users:

For people who rely on a screen reader, the missing alts would be a serious problem if the images were important, but only a minor irritation if they don’t convey any significant content or functionality.

But of course, the lack of adequate text alternatives can affect other people such as those with slow internet connection who turn off images in order to reduce the time it takes for pages to load. They might be cross if they have to turn on images just to see a picture of your aunt Mary or Uncle Bob.

For most screen magnifier users, the failure to include a couple of alt attributes is not likely to be a problem, but inadequate colour contrast could well be.

And, those with an impaired ability to distinguish colours may not worry about missing alts at all, but the low contrast ratio could render all the text totally unreadable.

Slide 5

For the individual web user, the accessibility of a site depends on many factors:

1. For a start there are the personal barriers to web access that they might face, for example:

  • technological or environmental limitations,
  • a physical disability that might necessitate the use of an assist device, or
  • a cognitive, learning or language problems that make the content of a page hard to understand.

2. Then we need to consider the actual quality of the website code. Has the site been prepared in a way that will allow the content to be accessible.

3. Then there is the ability of the user-agents, such as browsers and screen readers, to present the content of the page in a way that the user can perceive.

4. And finally, how skilful is the user in using the browser and/or assistive technology they rely on to access the web. It is wrong to assume that most people know how to use the accessibility features of a browser or computer operating system, or that all assistive technology users are expert users of their technology.

Slide 6

Although web accessibility should be primarily about how well people can access content, over the last few years the conversations have been increasingly about complying with rules, in Australia at least, and maybe many other countries as well.

For example, at the beginning of 2010 the Australian Government adopted WCAG 2, requiring the sites of all government agencies to move to double A compliance by the end of 2014 as part of a National Transition Strategy.

But compliance with a set of predetermined guidelines, no matter how comprehensive they might be, is no guarantee of accessibility, a fact well recognised by the W3C in the introduction to WCAG 2.0.

Slide 7

How often have you had clients ask does my site comply WCAG? They often have no real understanding of what it might mean, just that it something they are supposed to ask about.

 Slide 8

And even within the web community WCAG 2.0 is often misunderstood.

You still hear people with many years experience producing high quality web content or tools saying things like “you can’t use JavaScript if you want to comply with WCAG”.  The whole move to technological neutrality in WCAG 2 seems to have washed over them without raising so much as ripple of understanding.

Same thing with the difference between ‘normative’ Guidelines and Success Criteria and ‘informative’ Techniques. Many people interpret the WCAG techniques as Rules, with a capital R; Even in discussions of topics on the WAI interest group mail list.

I sometimes come across very conscientious and well meaning developers, who become pre-occupied with the idea of complying with as many techniques as possible for each Success Criteria. Often this is unnecessary and sometimes counter-productive when it comes to improving overall accessibility of a page element.

Slide 9

Working out if a page is likely to cause any accessibility problems is not rocket science, but then again, it is not a piece of cake either.

With a bit of knowledge and a few tools it is pretty easy to get a good idea if a site does or does not fully comply with WCAG 2. However, determining the accessibility implications of non-compliance, and what can be done to overcome it, does take a bit more work and experience.

 

Slide 10

When it comes to determining the accessibility of websites, the discussion is often polarised around two simplistic choices:

  • A compliance or conformance- based approach that usually involves a checklist of criteria;
  • or, some form of user testing by people who have different disabilities and/or who rely on different assistive technologies.

Both approaches have their strength and limitations, and neither can provide a reliable declaration about the accessibility of a site on its own.

Ideally, any thorough accessibility evaluation should involve both approaches, but the constraints of budgets and time often mean that this is not possible.

Slide 11

In order to help illustrate some of the complexities involved in determining if some web content is accessible or not, I have prepared this very simple and innocuous looking form. The form has just five text inputs, imaginatively labelled text one, text two etc.

The accessibility of this form, and all other web content, can depend on a variety of factors, but fundamentally it comes down to a question of how well all web users are able perceive and interact with the component.

Screen reader users, for example, need to be able to easily identify the purpose of each form input, and people who are unable to use a mouse need to be able to access all elements of the form with the keyboard.

But, for the purpose of this talk I am not concerned about anything other than how these five form inputs are identified, or labelled.  They all look the same visually, but the ways they have been coded is different, and are they all accessible?

What sort of result do we get when they are tested with screen readers?  And, what happens when we test for strict compliance the Web Content Accessibility Guidelines?

But first, a quick reminder of the relevant WCAG 2 Sufficient Techniques for identifying form inputs.

Slide 12

It seems to me, that there are three Level A Success Criteria that relate directly to the identification of form inputs:

  • 1.3.1 Info and relationships
  • 3.3.2 Labels or instructions
  • 4.1.2 Name, role, value

There is also the Level double A Criterion 2.4.6 Headings and labels, which canvasses much the same a 3.3.2 when it comes to identifying form inputs.

 

Slide 13

At this time, the W3C suggest two Sufficient Techniques for identifying form inputs:

  • H44: Using label elements to associate text labels with form controls (HTML)
  • H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)  

Slide 14

And, one Advisory Technique which uses WAI-ARIA

  • ARIA1: Using the aria-describedby property to provide a descriptive label for input controls (ARIA)

So, how does our five input form perform with screen readers.

I will run through the form using NVDA, a free screen reader which I am sure all of you are very familiar with and hopefully support with the occasional donation. If not, please do because they whole thing is run by a couple of very bright young Australians with very limited resources.

I use NVDA with an Australian voice, Nicole, from Ivona. I use the Australian voice because to my ear it is easier to understand than the standard e-speak voice.

Slide 15

A checklist conformance review usually involves someone manually checking a site or selected pages from a site often using a variety of tools.

You can run automated tools right through a site to see how well it conforms, but these just provide a snapshot or overview of likely issues, many of which will require later manual checking to verify.

Tools are just that, tools!  They are something to help you do what you need to do. Accessibility tools can only measure things that can be measured programmatically, like, does an image has an alt attribute. But, they can’t tell you if the alt attribute is appropriate.

These are just some of the tools I use when checking the accessibility of sites. But today I am going to use my old favourite the WAT toolbar developed and maintained by Steve Faulkner, who now works for the Paciello Group.

Slide 16

Well with NVDA, it seems that all of the inputs can be identified when just reading down the form. And,  all apart from number 4 can be identified with ease when filling the form in.

When we check the page with the WAT toolbar it indicates:

  •  the first input has an explicitly associated label,
  •  inputs two and five have label elements that don’t contain the “for” attribute,
  • And, input 4 appears to have an “id”, but no label.

Slide 17

The WAT tool bar, or an examination of the page code, quickly tells us that Input three is identified with a title attribute and, as we saw earlier, title can be used when it is not possible to use a label.

However in the form we do have a visible label for text three, but if we leave aside the question of whether or not we should in fact be using the label element in this case, we know that title attribute can be used to identify form inputs and still comply.

So Input 1 has an explicitly associated label and Input 3 uses the title attribute, but  what about the other three inputs.

Slide 18

Text two was clearly identified by NVDA since both the label and the input are inside the label element. Although, this is quite acceptable from a HTML specifications point of view, it is not provided as one of the technique examples in WCAG 2.0.

As far as I can see, the reason it is not cited as a Sufficient Technique is because some years back screen reader support for this was patchy.  But with modern screen readers today, it seems to be pretty good – so let’s call that a MAYBE.

Slide 19

With Text Four, the answer is simple: Since there is no label and no input title attribute, there is no accessibility API for the screen reader to hang on to. So that is clearly a NO.

Number five is more interesting because here we move into the realm of WAI-ARIA and the advisory technique about using ARIA-DESCRIBEDBY to provide descriptive labels. Even though this is an advisory technique only, it appears to be well supported by recent versions of commonly used screen readers and is consider an acceptable way of complying by the WAVE tool, so I think we can call that a YES.

Slide 20

So back to the question: Are all these form inputs accessible?

Well, they can all be identified by modern screen readers at least. And all, with the exception of number 4, have identifying information that can be exposed to screen readers via the API.

But when it comes to WCAG 2, in my opinion only text input one, which uses an explicitly associated label, unambiguously complies with WCAG 2.0 Success Criteria, however I think we can say YES to Text One and Text Five.

At the other extreme, text input four unambiguously doesn’t comply. So that is clearly a NO.

The remaining two are open to interpretation and discussion. For me, things like this are the exciting challenge with web accessibility today.

Slide 21

When WCAG 1.0 was released in 1999, Ajax was just a cleaning product and Prince told us it was a great time to party.  Back then Web content technologies and assistive technologies were much more primitive than what they are today and it was relatively easy to set criteria for determining what was accessible.

A good starting point was to just say if it ain’t basic HTML forget it, or provide an alternative. And, none of this fancy JavaScript stuff thank you very much!

Oh how the world has changed, and it’s time to stop pretending its 1999.

Now, web developers and clients are pushing the accessibility envelope everyday by wanting to include more sexy elements on the page and greater interactivity.  For example, during the last year or so, there seems to have been a growing fascination with providing sliders for users to input information and then displaying the results in a graph.  I can’t for the life of me see what is wrong with text inputs and a data table; but then I guess I am just a bit old-fashioned.

I now want to talk about another way of identifying accessibility issues that I have been playing with for the last year or so.

Slide 22

While checklists of criteria may provide an indication of whether or not a site complies, they don’t usually provide much information about the likely impact non-compliance may have for web users with disabilities.

During 2011, I began looking at ways we might consider the accessibility of web content from the perspective of the likely access barriers it might present to user.  One of the main motivations for doing this was to find a way of helping clients understand the significance of accessibility issues on their sites and prioritise their efforts in correcting them.

In part, this was a reaction to the look of bamboozled panic the acronym WCAG caused on the faces of some clients. Sadly, sometimes as a result accessibility experts who seem more interested in generating fear, and perhaps work, rather than helping clients make the content of their sites more accessible to as many people as possible.

At the end of 2011, I suggested the Access Barrier Score system which aims to provide a measure of how often barriers to accessibility occur in a site, and the likely seriousness of those barriers. This was the precursor of the Accessibility Priority Tool which I will outline in a few minutes.

I would like to stress, neither the 2011 Access Barrier Score or the 2013 Accessibility Priority Tool are intended to replace WCAG 2.0, but to be used in conjunction with it.

Slide 23

Before discussing the recent Accessibility Priority Tool, I think it might be worth looking briefly at the original Barrier Score system.

The Access Barrier Score system is basically an excel worksheet containing 26 common accessibility barriers.

The worksheet records the incidence (or frequency), and severity of each potential access barrier as determined by an experienced accessibility evaluator. These scores then generate a “Remediation Priority” ranging from ‘Critical’ to ‘None’ which can be used by developers and site owners to prioritize those issues that need to be addressed. I am most grateful for the help I got from Andrew Downie in making the Excel sheet work.

Over the last 12 months I have been using the Access Barrier Score when reviewing the accessibility of websites and I have provided a completed ABS sheet in conjunction with my reports on the accessibility of sites.

The feedback from clients and web developers to the ABS sheet has been generally very positive. Most clients reported the worksheet made it easier for them to see the extent and severity of problems and they also found the Remediation Priority generated by the system useful.  Over the year, I have also received suggestions from clients, developers and accessibility practitioners about how the system might be improved.

Slide 24

Here’s a brief overview of the changes that I made in preparing the Accessibility Priority tool earlier this year:

First,  the labels of a few columns has changed, most importantly the old “Remediation Priority” has been replaced with  “Access Barrier Advice”. This was mainly done to  stop people being too literal when interpreting the information in this column

I have also introduced a new column, “Importance Ranking” which I will talk about in a few minutes.

When preparing the original Accessibility Barrier Score worksheet, I was very keen to keep the number of barriers as low as possible in order to reduce the risk of information overload. This meant that some issues got combined and others were overlooked. For example issues relating to keyboard operability were contained within one barrier.

The 26 barriers identified in the 2011 worksheet have been expanded to 33 with the Accessibility Priority Tool.

Slide 25

Also, as a result of feedback, the priority tool introduces two new categories of access barriers.

  • Use of Other Technologies: This has been included because many sites now use third-party components such as social networking tools or ticketing systems, that are often inaccessible.  And, sometimes the major, or only, cause of accessibility problems on a site relate to inaccessibility of these tools, so I thought it would be useful to provide a way of highlighting them.
  • Device Usability: When reviewing the accessibility of sites I am being increasingly asked to comment on how well they will work on an iphone or tablet, so I have introduced this new category as a way of providing some basic feedback on the usability of sites with different devices.

Slide 26

I now want to talk about the new Importance Ranking column.

I work with many different organizations, ranging from small not-for-profits with perhaps one part-time web worker, to government agencies and corporation with large web teams, numbering in the hundreds. And, while the easy to understand information provided by the original Access s Barrier Score system was generally useful, among the feedback I got from the larger organizations was the desire for a tool that could reflect their requirements and capabilities, as well as the needs of their site users.

As such, the focus of the Accessibility Priority Tool has shifted from being something for individual accessibility evaluators, to a tool that can be used by large organizations where many different people may be responsible for determining and maintaining the accessibility of the web content.

2013 Accessibility Priority Tool allows the organization, and not just the person doing the accessibility evaluation, to have an input into the perceived importance of different accessibility barriers in the worksheet. Thereby, bringing greater consistency in the prioritization of issues from the results obtained by the different people who evaluate the accessibility of web content.

Importance Ranking should be determined well in advance by the organisation, depending on their circumstances and resources, e.g:

  • Regulator want to set national of industry agenda
  • Organizations meeting the specific requirements, and the needs of their users and site audience
  • Organisations highlighting the issues that they have the in-house capabilities to address immediately.

Slide 27

Determining the Importance Ranking for each access barrier, will require an awareness of the needs of the organisation and primary audience for the site, as well an understanding of the general principles of web accessibility.

I also believe that people using the Accessibility Priority Tool worksheet when reviewing the accessibility of a site should have experience in evaluating web content accessibility, and I imagine they will probably use a range of accessibility testing tools and a screen reader, for example NVDA.

I am going to now walk through the Accessibility Priority Tool Excel worksheet. (The  following slides outline the issues discussed during the demonstration).

Slide 28

Starting, with the Importance ranking (column H).

As I just said, this should be done in advance. With large organisations and government agencies this will probably be done by the in-house team responsible for determining and monitoring the accessibility of sites.

For small organisations it should be undertaken by an experienced accessibility evaluator, but it should still be done in advance of the actual evaluation and in close consultation with the client organisations.

(NB: The Importance Ranking values that are already entered into the worksheet are my perceptions of the relative importance of issues. These can, and should, be changed as required to meet the specific needs of different organisations.)

The Importance Ranking values are used by the Excel formula when calculating the advice generated about each access barrier.

I envisage that once the Importance Rankings have been decided and entered, this column will usually not be displayed when the Excel worksheet is being used during the evaluation of web content.

Slide 29

A person using the worksheet when reviewing a site will mainly be concerned with the Incidence score, column D, and the Severity Score, Column E.

Incidence score is a measure of how frequently the person using the tool believes that a particular barrier occurs on the site, or how frequently the way a site component is used does not meet the relevant accessibility requirements. The score is not a raw measure of how often a problem occurs, but rather an indication of how often, in percentage terms, the use of particular site component is likely to cause problems.

While evaluating the site, the person doing the evaluation enters an Incidence Score in Column D for each access barrier item using a five point scoring system:

0 – There is no incidence or occurrence of a failure to make the component accessible.

1 – The use of the page component or element causes access problems up to 25% of the time.

2 – The use of the page component or element causes access problems between 25% and 50% of the time.

3 – The use of the page component or element causes access problems between 50% and 75% of the time.

4 – The use of the page component or element causes access problems more than 75% of the time.

A few examples:

  • If there are 10 images, and 4 of those images have no alt text, the lack of a text alternative could cause a problem 40% of the time images are used, so the incidence score would be 2.
  • If a site has just one CAPTCHA and it is inaccessible; then 100% of the times CAPTCHA is used could cause a problem, so the incidence score would be 4.
  • If a site contains a number of pages with good content headings and sub-headings that use the correct mark-up, but on one page there are a few sub-headings that don’t use heading elements, then incidence score for the use of heading elements would be 1.

Slide 30

The Severity score (Column E) is used to record the likely impact the accessibility evaluator believes each barrier will have for someone with a disability.

The impact is rated with a Severity score of 1 to 5, where 1 is a minor inconvenience, and 5 indicates an extreme problem that will totally prevent some people from accessing the site content or functionality. For example:

1. Minor inconvenience: Not likely to prevent anyone from accessing content, but could be a minor irritant.

2. Minor difficulty: Not likely to prevent anyone from accessing content, but could affect the ability of some people to use a page.

3. Average difficulty: Could make it difficult for some people to access content and use a page.

4. Major problem: Could prevent some people from accessing or using page content.

5. Extreme problem: Will prevent access to sections of the site or the ability to perform required functions.

Allocation of the severity rating will of course be subjective, and as such, is always liable to be influenced by the experiences and knowledge of the person making the decision.  This is one of the reasons why I believe it is important for anyone using the suggested Accessibility Priority Tool to have some knowledge of accessibility and assistive technologies.

Slide 31

The Access Barrier Advice is determined by the APT tool from an Excel formula which uses:

  • The Incidence and Severity scores entered by the accessibility evaluator, and
  • The Importance Ranking values entered by the site regulator or owner in advance.

The Access Barrier Advice for each item is then presented in Column F using the following terms: None, Low, Medium, High, Very High, and Critical.

NB: The Access Barrier Advice generated by the APT worksheet is just a suggestion and as such should not be solely relied upon. Since, the advice may not accurately reflect the significance of a serious or important issue when the incidence is low.  For example, a critical image with a missing text alternative among many (less important) images with good text alternatives.

Slide 32

The Accessibility Priority Tool is not intended to be an automated process that can tell you what to fix on your site and when. Rather, it is a tool to help site managers make these decisions.

The comments section (Column G) is an important part of the tool since it allows the evaluator to provide their subjective impressions of the likely impact of potential access barriers, and highlight those that they believe will be most important.

For example, as I just mentioned, the Access Barrier Advice generated by the Excel formula may under report the importance of critical issues that occur infrequently: If there is one critical image with a missing text alternative among many less important images with good text alternatives, the APT will generate a maximum Access Barrier Advice of “High”.

However the image might be absolutely essential to the ability of people to use the site, say a login button, and this fact would be recorded in the comment section so that it is available when decisions are being made about prioritising efforts to correct accessibility issues on the site.

Slide 33

I would like to finish with a few comments about some of the lessons I have learnt and some points for discussion.

  • First, to pick-up on something I have already mentioned, I believe it will be important for the setting of the Importance Rankings to be done by someone with knowledge of accessibility. And, the person using the worksheet when reviewing a site should also know about accessibility.
  • Second, given the complex nature of websites and diversity of user needs, I don’t think it is possible to make an automated system that can reliably priortize issues for remediation. The outlier issues, like low incidences of critical failings or high incidences of minor irritants are always likely to present anomalies in the results.
  • Third, finding the balance between providing enough likely barrier items to represent the needs of people with disabilities, and the desire to have a tool that is not too daunting to use or difficult to understand. I am not sure I have it right, so if you want to try out the tool feel free to add, remove or edit the access barrier items as you wish.
  • Fourth, don’t use decimal points when preparing Excel formulas! Many thanks to Detlev for identifying this problem in the worksheet and it will be fixed soon, once again I hope with Andrew’s considerable assistance.
  • And finally, I would like to stress once again, this should not be seen as an alternative to WCAG when it comes to evaluating the accessibility compliance of sites. It is just a tool to help in the process of identifying and priortising issues that should be addressed.

In my experience, just telling a client or web developer that something is a problem they must fix can often lead to greater resistance or hostility towards the whole concept of web accessibility.  Most site owners and developers want to obtain some indication of the severity of the various problems you might see on their site so that they can prioritize their remediation efforts, for not all accessibility failings are equal.

Slide 34

I think this tool may be particularly useful to organisations that have a number of people monitoring the accessibility of sites. It considers both the needs of the organisation and the audience for the site, as well as input from experienced accessibility evaluators, when determining advice relating to each of the potential accessibility barriers.

Organisations can then combine this advice with knowledge of their own in-house accessibility capabilities when determining those issues they might be able to address quickly (the so called low-hanging fruit) and those that might take longer and require greater resources.

If you are interested in trying the Accessibility Priority Tool please do so.  Also feel free to modify it as you like.

All I ask is that you give me some feedback about how well it works and any suggestions for how it might be improved.

Slide 35

Thank you,

And, I think we have few minutes it there is anything you would like to comment on or discuss about both the Accessibility Priority Tool or my general concerns relating to the tendency of clients and regulators to view accessibility as just a series of items on checklist that have to be ticked-off.

Forgotten of Web Accessibility: CSUN2013 Talk

by
, , ,
Reply

On 27 February 2013, I gave the presentation “The Forgotten of Web Accessibility” at the 28th Annual International Technology and Persons with Disabilities Conference (CSUN 2013). Many thanks to the people who attended the session for their interest, comments and questions.

The slides from the presentation and the speaker’s notes follow:

Speakers notes

Slide 1

I spend a fair bit of my time watching people use the web, sometimes just out of interest or for personal research projects, but often because I am paid to.

Last year, I was asked to test how well people from a specific group within the community were able to use a site that had been made from them. And, a comment from one of the participants piqued my interest, leading eventually to the subject of this talk.

Slide 2

“I don’t use the web” is not a response you normally get from someone in front of a computer about to undertake some tasks using a website.

I was perplexed, here we were sitting in the computer room of an organisation that provides support for some of the most marginalised in the community, and I knew the participant had been recruited because he regularly visited the centre to use the internet.

“So, what do you do here”, I asked.

Slide 3

“I use Facebook, and sometimes to send email”, was the reply.

This got me thinking, and so for the remaining test sessions, rather than just asking a general question about how often someone uses the web or internet, I would have a bit of conversation with the participants about what they did online.

Slide 4

Hang on, some of you might be thinking, or screaming to yourself. This sounds like usability. What’s it got to do with accessibility?

Well, I don’t believe accessibility and usability are mutually exclusive. And furthermore, I am fearful that while the desire to separate the two might be beneficial to some assistive technology users,  it could have profound consequences for some other web users who find accessing content difficult.

I am particularly concerned that older and/or novice web users as well as people with cognitive or learning difficulties will find it increasingly difficult to access web content  if we don’t foster an approach that embraces both usability and accessibility.

Slide 5

Over the last decade the efforts of the W3C, accessibility advocates, and regulators in many countries have resulted in a web that is more accessible for many people, particularly those who rely on different assistive technologies.

A significant aim in the development of WCAG version 2 was to have guidelines that were technologically neutral.

In addition, the desire for a more reliable system of compliance testing meant that the inevitable blurring of the boundary between usability and accessibility was be avoided as far as possible. To quote the WCAG document:

“There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2.0, we only include those guidelines that address problems particular to people with disabilities.”

Slide 6

It is now much easier for people in many countries to go online. The relative cost of computers and internet connection has fallen significantly, and now free internet access is available in social spaces such as libraries, cafes and community centres.

Part of this race down the information superhighway, has been the growing use of the internet by government agencies to deliver government services, so much so that in some countries like Australia, it is becoming increasingly difficult to access some services if you are not able to use the web.

However, in the rush we are in danger of sometimes losing sight of the fact that not everyone can participate in this online revolution; a combination of geographical, financial, psycho-social and cognitive factors means there is still a great gap between the digital haves and have-nots.

The total number of internet users is increasing all the time, but perhaps more important is the increased diversity of people who are online.  It appears however, that many website owners and developers are either reluctant, or unable, to make sites that cater to the needs of these different sections of the community.

Slide 7

Although there are still vast disparities in the well-being of our fellow global citizens,  overall people are living longer.

  • In 1950, about 8% of world population over 60
  • 2005 it was nearly 10%
  • And the UN estimates that by 2050 it will be 22%

In developed countries, like Australia and the US, this  increase is more rapid, where for example, in all the years up to 2000 there were more people under the age of 15 than over the age of 60, but since then the situation, has switched and the gap is growing wider each year.

In the developing world, falling birth rates and improving economic circumstances is also causing shifts in the population profile, but at a slower rate.

Reference: UN World Population Prospects (2006) http://www.un.org/esa/population/publications/wpp2006/WPP2006_Highlights_rev.pdf

Slide 8

And, older people are increasingly going on line.

Research by PEW Internet into use of the internet by people in the US over the age of 65 found that :

  • About 15% were using it in 2000
  • 38% by 2009
  • And by 2012 the percentage of over 65s had increased to 53%

Reference: Most recent PEW report (June 2012) http://www.pewinternet.org/Reports/2012/Older-adults-and-internet-use.aspx

I don’t have comparable figures for Australia, but in 2011 the Australian Bureau of Statistics released the result of their Online at Home survey conducted a couple of years earlier.

It reported, 31% of people over 65 were online, with about half using the internet daily.

Reference: ABS Online at Home http://www.abs.gov.au/AUSSTATS/abs@.nsf/Lookup/4102.0Main+Features50Jun+2

Slide 9

At the CSUN 2011 conference I gave a presentation called “Improving Web Accessibility for the Elderly”. The presentation considered how people over the age of 60 use the web, how much they use it and what they use it for.

We surveyed or tested a total of 155 people over the age of 60, and the main reasons they gave for using the Internet were:

  • Keeping in touch with family and friends, and
  • Finding health related information.

These findings are similar to those reported by PEW Internet in 2010.

Most said they experienced difficulties when attempting to use the web and I will talk a little more about this in a few minutes.

Slide 10

According to the W3C Web Accessibility Initiative, the main age-related impairments that older people have which could affect their ability to use the web include:

  • Vision loss or decline – e.g. fall in the ability to read and distinguish between colours.
  • Reduced physical dexterity and fine motor control, making it difficult to use a mouse and click small targets
  • Hearing loss making it difficult to hear generally and separate what you want to hear from competing background sounds, as occurs when listening to a conversation in a crowded room.
  • Decline in cognitive ability including reduced short-term memory and difficulty concentrating.

The WAI advises that since these issues overlap with the accessibility needs of people with disabilities, sites that are accessible to people with disabilities will be more accessible to older users as well.

Well yes, sort of:

Those issues relating to declines in vision, hearing and physical abilities may be well catered for under the existing WCAG arrangements.

However, those relating to a decline in memory or the ability to concentrate, understand instructions and make decisions are not well catered for.

Many issues similar to these maybe be experienced by a wide range of people, and not just the elderly. For example, novice web users or people with reading difficulties.

I now want to spend a few minutes talking about a couple of projects I have been involved in that touch on some of these issues.

Slide 11

In 2007, I was asked to test the usability and accessibility of a website for people who were homeless or in public housing. It was expected the site would be primarily accessed from computers and/or kiosks in government offices and welfare organisations.

Five years later, in 2012, I had an opportunity to review another site prepared for a target user group where there was some striking similarities in terms social marginalisation.

During the 2012 project, as a result of comments like “I don’t use the web, I use facebook”, I found myself reflecting on some of the changes in how the test participants of today understood and used the web when compared to those five years earlier.

(For reasons of privacy and client confidentiality I cannot provide specific details.)

Slide 12

With both projects, many of the participants were from lower socioeconomic status groups in the community and included a significant proportion who are largely marginalised in terms of education.  As a result, many had lower-level reading abilities and limited access to computers and the internet when compared to the general community. Also, in both projects a number of the test participants were over the age of sixty.

However, as we will see, the online abilities and experiences of the participants from the two projects were quite different.

Slide 13

In 2007, while all the test participants had used the internet, the amount of use was generally very limited and very few had the ability to access the web on a regular basis. Only 28% went online for five hours or more per week

However, after being introduced to the test-site they appeared to be genuinely interested in using it to find information and actively explored the various navigation options.  Most appeared to develop an understanding of the site navigation system with relative ease and participant comments  included:

  • I just love using the computer – I didn’t realise there was so much you could do.
  • I thought it was tricky at the beginning because there is all these different sections to look at for where to go (for information)

Slide 14

As might be expected, all the test subjects in the 2012 project had greater opportunities to access the web than those in 2007.

50% of the participants reported using the internet every day, and all-up 80% said they used it at least once a week. Most went online either via computers owned by family members and friends, or through various community centres with computers and free internet access.

Slide 15

Given greater opportunities to use the web, for many of the 2012 participants going on line was rather ho-hum, as you might expect, and not the exciting new adventure that the participants from five years earlier seemed to find it.

However, this “been-there/done-that” attitude seemed to translate into less excitement or curiosity about the technology. The web was just about finding information, such as sports results or what your friend is doing and not something to experience.

Now this in itself is not worrying, or even particularly interesting, but an apparent lack of interest, or difficulty, many 2012 participants had in learning the basic concepts of website navigation I did find interesting.

Slide 16

The basic structure of websites and standard navigation systems seemed to confuse at least some of the participants in 2012.  When undertaking tasks with the site, most participants either did not use the main navigation menu, or did so very reluctantly.

Even after using the site for about an hour several were still confused by the common navigation terms “Home” and “About”, and tended to see them as relating directly to themselves or their situation, comments included:

  • Home is that Australia or where you live?
  • Is Home something to do with the home you came from?
  • What is About? Is that about the information you are looking for.
  • What’s the difference between Home and About?

Slide 17

This apparent decline in the ability to understand, or at least a willingness to learn, the navigation systems common to many sites may not be confined to novice web users or people with lower-level reading skills like those involved in the 2012 project.

Instead, an emerging ‘Facebook effect’ may help explain why some regular web users today are less likely to participate in the exploratory, web-surfing behaviour of the past.

Slide 18

Facebook recently announced its one billionth account; that is a lot of people, even if all these accounts do not represent separate individuals, and so it is reasonable to assume that Facebook could have an effect on the way people perceive the web and operate in it.

On Facebook (and other social networking sites such as Linkedin) focus is on the individual and their friends, and the navigation systems reflect this focus with the link ‘Home’ taking the user back to their first page, or Wall.

Within this context, it is possible that there is a growing uncertainty about common site navigation labels like ‘Home’ and ‘About’, and this uncertainty requires them to think more about selecting one of these items and hence a reluctance to do so. As Steve Krug famously said “don’t make me think!”

This breakdown in a common understanding of what is website navigation is likely to be exacerbated by the increasing use of application-based interfaces for a wide range of web activities ranging from banking to train timetables. And, who knows what the long-term impact will be of the move to touch screens with swipes, pinch to zoom etc.

Slide 19

When it comes to finding information on the web in general, or on an individual site, over the years I have noticed that many web users are either ‘surfers’ or ‘searchers’.

Of course, this is not a hard and fast rule, and all of us probably indulge in both at times, but it seems that when seeking information some people are more likely to surf from site to site and use the navigation within sites, whereas with others, the first inclination is to search.

In 2004, Google accounted for less than 50% of all search engine use and the next most popular at the time, Yahoo, was at 26%. But by 2012, 83% of searchers use Google, with Yahoo still second, but  at a distant 6%.

Google now logs about 2 billion search requests a day, from approximately 300 million people. And, for many people Google is the standard entry point to pages deep within websites. Why bother with learning how to use a site to find what you want when Google will do it for you.  To quote one recent test participant:

I normally just type the words in Google and it comes up. I always select one of the top results, because if I type a good question it will be there.

But, what happens if it’s not there?

Slide 20

A combination of this growing reliance on Google, and a Facebook effect, where the preoccupation is on the individual, may mean that it is time to reconsider some basic usability and accessibility principals.  And in particular, the potential accessibility impact this may have for web users with cognitive impairments and/or limited internet experience.

I feel when the struggle some people have in understanding basic website concepts is combined with the growing use external search engines to locate information within a site, this must have implications for WCAG 2, in particular,  “Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.”

Slide 21

In a practical sense I think there are a number of issues that need to be considered:

  • Should we continue to use common navigation labels like “Home” and “About”? Depending on the primary audience for a site, it may be better to be more specific, for example by using the name of the organisation.
  • Perhaps we should give greater consideration to Success Criteria 2.4.8 (“Location: Information about the user’s location within a set of Web pages is available”) and associated Technique G65 about the use of breadcrumbs. This Success Criteria is at level AAA and so often ignored, but since users are increasingly going directly to internal pages, sometimes deep within a site, it could help them determine where they are.
  • Maybe there should be a slight shift in the focus of SEO from promoting goods and services (content) to actually helping people find what they want within a site.

Slide 22

On a slightly different note, with the ubiquitous web of today it is hard to ignore the warnings and tragic stories, like those associated with Nigerian scams and cyberbullying.  And, fear is one thing that did seem to get through to the 2012 participants. But whether their fears are always rational or justified is another question.

For example, one of the test tasks in 2012 involved the participants finding a link to some information in the form of a PDF. The link contained the word “download” and this led to about a quarter of the participants indicating a belief that downloading anything would be a serious security risk. For example I heard;

  • I always avoid anything that says ‘download’. It’s safer.
  • I don’t think I would download this. I don’t download in case I get into trouble.

And in the case of this last comment, trouble came in the form of condemnation from more tech-savy teenagers who have become self-appointed internet gatekeepers.

Slide 23

Now, rather than the differences I had noticed when testing these two site, I would like to look at a similarity.

The one striking thing the 2007 and 2012 sites had in common was a fondness for words, often big words and lots of them.  And, in both projects, many test participants found the content difficult to read and understand.

Slide 24

Although tools for testing reading levels are rather crude, depending as they must on components of the text that can be measure mathematically, they can provide an indication of what is required.

And, I sometimes use these tools to help communicate to the owners of sites why they should look at ways of making their content simpler. For example, this table provides the results from testing the reading level of a sample of pages from the 2012 site using two measures of readability:

  1. Flesch Reading ease – higher the score the easier content is to read. Maximum score is 100  and for plain or simple English a score of 60 plus is advocated.
  2. Flesch-Kincaid grade – measure of number of years of school required to understand the content. (Maximum score is 12).

Not surprisingly numbers like 49.5 and 9.91 for the 2012 pages are not particularly meaningful to most clients, so I also tested some articles on the site of Daily Telegraph, a mass circulation tabloid newspaper in Sydney to provide a comparison.

And, as you can see when a reading ease score of 60 is considered necessary for easy reading – the Telegraph scored 68.7 compared to 49.5 for the tested site.

And, when it comes to the number of years school required to understand the content the difference is even more stark – less than 5 compared with nearly 10.

Slide 25

It can be very hard to get a firm grip on how many people have reading difficulties. On one, rather simplistic level, Australia has a very high literacy rate; 99% can read and write according to Wikipedia, along with the US, UK, NZ, Canada and many other similar countries.

However, a more realistic impression can be gained from the ‘Adult Literacy and Life Skills Survey’ conducted by the Australian Bureau of Statistics in 2006, as part of an international study by the OECD.

This survey looked at a number of literacy components, or domains, using five levels of ability. And found:

  • 17% of the adult population had literacy at, or lower, than the minimum level.
  • And 46% were at a level that was below what the survey developers regarded as the “minimum required for individuals to meet the complex demands of everyday life and work in the emerging knowledge-based economy“

And, I expect the results in the US would be very similar to those in Australia.

I know how difficult it can be to get a handle on the extent of literacy problems in the community. For many years ago, in a pre-web life, I was commissioned to do research and prepare resources for the UN International Year of Literacy in 1990.

And, I have two strong memories of this research: First, the extent to which reading and writing problems are under reported in the community; And, second the extremely diverse and complex nature of the issue.

Slide 26

Over the years,  there has been a significant under reporting of the number of people who have problems reading, due in part to the erroneous assumption that people who find reading difficult are somehow stupid.

There are many reasons why some people have reading problems and of course some relate to intellectual impairments. But there are a variety of other causes, in some cases it might just be the simple fact that they didn’t have the opportunity to learn or problems with their vision, but it could also be due to wiring problems in the brain, inability to identify or sound-out different components or words, the poor processing of visual information and not forgetting the sometimes contentious issue of dyslexia.

Whatever the reason, there are many examples of brilliant and highly successful people who have, or had, difficulties reading including:

  • Innovators like, Alexander Graham Bell and Thomas Edison.
  • And scientists like Michael Faraday and Albert Einstein.

When it comes to the accessibility of web content, the individual causes of reading problems is not particularly relevant. What is important however is the fact that in countries like Australia, somewhere around 20% of the adult population find reading text difficult.

Slide 27

WCAG 1 explicitly recognised the problems faced by people with reading and learning disabilities with a Priority 1 Checkpoint; “14.1 Use the clearest and simplest language appropriate for a site’s content”.

Sure, this checkpoint was hard to interpret, hard to measure and often ignored, but at least it gave us something to fight with.

In the desire for accessibility purity, and guidelines that it is hoped could be more reliable tested by machines or humans, WCAG 2 has effectively downgraded those issues that traverse the boundary between usability and accessibility. Sadly this has meant that many of the Success Criteria that are particularly relevant to people with cognitive, learning or reading difficulties are now at triple A, and so largely ignored.

I should make it clear that I am aware that WCAG 2 Success Criteria levels are determined by a variety of factors, and importantly provide an indication of how difficult complying with a criteria is likely to be. In this way, they are very different to the priority levels used in WCAG 1.

However, from a practical perspective, regulatory requirements are based on Success Criteria levels, for example Double A by the end of 2014, and so they have a direct influence on how well people with different disabilities will be able access web content.

Slide 28

So, we have gone from one vague Priority 1 checkpoint requiring the use of simple appropriate language, to three triple A WCAG 2 Success Criteria. Two relate to the use of ‘unusual words’ and ‘abbreviations’, and then we have this dossy:

3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

While the language used in the Reading Level Success Criteria may be more precise than that used in the WCAG 1 checkpoint, I am not sure it is any more meaningful. But of course, these aren’t the only Success Criteria relevant to people with cognitive, learning or reading impairments.

Slide 29

This is a map of Success Criteria that can have impact on how easy web content will be to read and understand.

By meeting the level A and AA Success Criteria indentified here, content is more likely to be accessible to assistive technology users, as well as people with cognitive and reading difficulties. However, there are also eleven triple A Success Criteria, that are important but often ignored.

For example:

Visual presentation covers many important reading related issues including:

  • Line length (ideally not more than 80 characters)
  • Don’t justify text causes “rivers of white”
  • Text size – not too small. I long for the day when developers stop setting text at 90% or .9ems and leave it at the default or maybe even make it a little larger.

Links: For single A compliance links need to make sense within the context of the surrounding information, however if this surrounding content is hard to read it is of little value. Screen reader users as well as people with reading problems love the text used in links to be clear, concise and meaningful.

When it comes to Headings: The single A Success Criteria 1.3.1 requires headings to be marked up properly and the double A Criteria 2.4.6 says the actual headings need to be descriptive, but Criteria 2.4.10 at triple A is the one that says you should break up long documents into different sections identified with headings.

Readability I have already touched upon

Slide 30

I believe we need to spend a little more time thinking about how different people find information on websites, and how easy it is for people to read and understand that content once they have located it.

I know many of these issues are at triple A, and so not required to get a tick of approval from authorities, but they really are more important than that.

I would now like to return to the issue of older web users that I mentioned a little earlier and give an update on some of the work we have been done in this area recently.

Slide 31

My CSUN 2011 paper reported on the results of an online survey of 124 people over the age of 60,  as well as a survey and user-testing with 31 people in Sydney. The oldest person we tested with was a sprightly 93 year old lady.

Nearly all of the participants said finding the information they were after was a major difficulty, with just over 80% saying that when using the web this was a problem sometimes or often. And, perhaps not surprisingly, more than half said moving or flashing content was a problem sometimes or often, with most nominating adverts the main culprit.

50% reported the size or the colour of the text on web pages was a problem.

Slide 32

However, when the people were specifically asked in a later question, if they had difficulties with the colour or the size of text on pages: 48% said that text size was a problem at least some of the time; and, 23% mentioned colour.

These numbers are rather interesting, but much more worrying was the fact that most had no idea how to overcome these difficulties when using a computer.

Many different ways of overcoming the problem of text being too small were offered, the most tragic explanation from a man in his sixties who needed information from a government website. He resorted to printing the pages out at home and then taking them to the local library so that he could make the text bigger by enlarging the page on a photocopier.

Slide 33

Most browsers now have a variety of controls for either increasing the size of text on the page or zooming-up the whole page. However less than 40% of the people we interviewed were aware of these browser tools.  And, I suspect that this lack of knowledge is not just confined to people over the age of sixty.

There are website developers who are concerned about accessibility issues, and some sites do provide users with advice on accessibility related matters like how to increase text size. This information is often obtained by clicking a link labeled “accessibility”. During our interviews we asked participants what they thought the accessibility link might mean. And, only 10% appeared to have even a basic idea about what the term might mean in relation to the web.

When also asked about in-page resize tools, which are often icons in the top-right corner of the page. Nearly all the participants maintained they had never ever seen them, this was in spite of the fact that one of the pages used in the testing had the Big-A  Lttle-A icons at the top.

Slide 34

I and a number of friends, including  Russ Weakley,  have been working on this problem on-and-off over the last year. We feel it is likely the solution will have a number of main components:

First, the information need to be easy to understand. And to that end, we prepared a number trial pages with a simple text explanation about what to do and a short video demonstration. These pages are currently in the “Having  Trouble Reading This Page” section of my new site

The first page in this section describes the standard and well supported technique for zooming with the keyboard.  And contains this short video (shows video).

The second issue was how to get information relating to the myriad of devices and browsers that people use. And for this, we thought it might be possible to turn to the wider accessibility community.  The hope is that people who were interested in the general idea and who use different operating systems and browsers, would be willing to prepare simple text instructions and a video describing what is required with the systems they are familiar with. The information from these different sources would need to use the same basic format or template.

Slide 35

Then there is the question of making the information available in a way that will be easy for site owners to implement and users to identify.

This slide outlines the basic concept.  At the centre, there is a server where accessibility people can put information about how to change the size of text or the  use of colour on a webpage. And on the other side, those site owners and developers who wish to use this information, would be able to pull it down from the server and incorporate it into their sites when requested by site visitors who need assistance.

But this of course, doesn’t address the problem of  how do we let site users  know  a site contains  information that might help them, and how to find it.

Slide 36

To answer this question, we came up with the idea of have an icon or  widget that site owners or developers could put onto pages.  Something like this one shown on a simple mock-up showing the front page of my site. At the top of the page there is a button with the label “Customise this page”.

The words used here are just a suggestion and maybe someone could come up with something better.

Behind this is a tool, there is some scripting that sniffs out the operating system and browser that are being used. And, when the site visitor clicks the button or icon, a dialog appears with information relating to their specific operating environment.

Slide 37

The dialog would provide provides basic options for changing text size and colour using  the browser . There would also be a link to making the changes at an operating system level, and probably a link to a page with basic information in case a particular operating system/browser  combination can’t be identified.

But, in our example here, the tool has identified the person is using Windows 7 with Internet Explorer 9. And, if the site visitor just wanted to make the text a bit bigger, they would then click the first button, “See how to change your browser’s font size”.

Slide 38

And get a new dialog with a video on how to increase text size and a short explanation of what is required in text.

I imagine this dialog would also contain a link to information about how to make the changes at a system level.

So that is the general idea, and our hope is to have a simple functional example using  one or two sites prepared in the next  few months.

I have no desire to develop this as a service, but I do believe that it could work and be really beneficial, so my hope is that someone is willing to take it  on – maybe one of the vendors, or the W3C, or anyone. So if you are interested or have any suggestions about who might be, please get in touch.

Slide 39

Thank you.

Here is my contact details, you can email me at rhudson@usability.com.au or get in touch via twitter.

Any questions or comments.

CSUN 2013 Presentations

by
, ,

I will be giving two presentations at the CSUN 2013 International Technology and Persons with Disabilities Conference starting next week. Both take a real-world look at what web accessibility means, how it is measured, and some of the people who may get overlooked in the process.

Accessibility is more than WCAG Compliance

Presentation time:  Wednesday February 27 at 8.00 am.

Since the release of WCAG 2 there has been considerable debate about how to determine the accessibility of websites. Unfortunately, this is often presented as two simple choices: either using a checklist to determine the level of compliance/conformance with the specific Success Criteria; or, undertaking some form of user testing by people who have different disabilities and/or who rely on different assistive technologies.

During this presentation, I will look at the advantages and disadvantages of these two approaches.

I will also report on my use of the Access Barrier Scores Excel worksheet, which was developed in November 2011 to help communicate the relative importance of accessibility problems, and  development of the new Accessibility Priority Tool, which aims to help organisations prioritise efforts to improve the accessibility of their website

The Forgotten of Web Accessibility

Presentation time: Wednesday February 27 at 9.20 am.

The web is becoming more accessible for many people, particularly those who rely on different assistive technologies. However, older web users, as well as novice users and those with lower-level reading skills still face significant problems.

During this presentation, I will compare two projects (one in 2007 and the other in 2012) that involved testing web content that had been prepared for target audience groups with limited internet experience and lower-level reading skills. The presentation will discuss changes in web-user behaviour over the last five years and how this might be affecting the way people to find information on the web today.

In the desire for accessibility purity, WCAG 2 has effectively downgraded those issues that traverse the boundary between usability and accessibility.  Sadly this has meant that many of the Success Criteria that are particularly relevant to people with cognitive, learning or reading difficulties are now at triple A, and so largely ignored. During the presentation I will argue that we should give greater consideration (weight) to some WCAG 2.0 triple A criteria, for example those in Guidelines 2.4 and 3.1

Accessibility Priority Tool

by
, ,

The Accessibility Priority Tool is a suggested mechanism for helping web content developers and organisations identify and correct issues that could reduce the ability of some people to access web content. The tool takes account of the needs and target audience of a site as well as a professional assessment of potential accessibility barriers when calculating an advice level for remediation. This advice level, in conjunction with the recorded information about the frequency and severity of each issue, can be used by the organisation to help prioritise efforts to improve the accessibility of their website.

The suggested Accessibility Priority Tool is not a solution to inaccessible web content, nor an alternative to the need for sites to comply with the Web Content Accessibility Guidelines advocated by the W3C. Rather, it is just a tool to help you decide which accessibility issues you should address now, and which you might be able to leave until a little later.

Accessibility Barrier Scores revisited

I have been a strong supporter of the W3C Web Content Accessibility Guidelines for more than a dozen years, and enthusiastically embraced the move to version two (WCAG 2.0) at the end of 2008. Although I continue to be a keen advocate for WCAG 2.0, I have in recent times become increasingly concerned by the tendency of some people to view web accessibility solely from the perspective of WCAG 2.0 compliance.

In November 2011, I discussed some of these concerns in the article “Accessibility Barrier Scores”. The article also outlined a suggested system for identifying potential web content accessibility barriers and their likely severity that could be used in conjunction with WCAG 2 when evaluating the accessibility of sites.

Over the last year, I have provided a number of clients with a completed version of the 2011 Access Barrier Score Excel file as an appendix to website accessibility review reports. In general they have found this appendix made it easier to see the extent and severity of problems and they also found the Remediation Priority generated by the system useful. I also received suggestions from clients, developers and accessibility practitioners about how the system might be improved.

Following this feedback, I have revised the scoring system and once again must thank Andrew Downie for his help with the Excel formulas. Thanks also to Russ Weakley, Janet Parker and Danny Thomas for their suggestions. As you see, I have also changed the name of the system to “Accessibility Priority Tool” (APT).

Introducing the Accessibility Priority Tool

I envisaged the Accessibility Barrier Scores system (2011) as being primarily an aid to help people evaluating the accessibility of web content communicate the relative importance of issues in a way that would be easy for clients to understand. The overall intention of the Accessibility Priority Tool is quite different.

This tool focuses on the needs of large organisations, such as government agencies, educational institutions or banking and finance companies, which may devolve responsibility for determining the accessibility of their content to a diverse group of people. The APT allows organisations to rank the perceived importance of accessibility barriers, in a worksheet that can be used by the different people who evaluate the accessibility of the web content, to identify and prioritise issues in a way that is consistent within the organisation.

The APT does not aim to measure how well a site might comply with WCAG 2.0. However the WCAG 2.0 Success Criteria related to the different accessibility barriers in the APT Excel worksheet have been included as a reference to aid users of the worksheet. These could be replaced with any other reference system (e.g. Section 508) that may be more relevant in a different environment.

Following feedback from Detlev Fischer (see comments) the attached Accessibility Priority Tool Excel file has been revised.

The differences between this tool and the 2011 Accessibility Barrier Score system, as well as a brief explanation of the reasons for these changes, are outlined below:

New Access Barrier Items

When preparing the original Accessibility Barrier Score, I really wanted to keep the number of access barriers as low as possible, but this meant that some issues got combined and others were overlooked. In hindsight I think I was a little too obsessive in this regard. The number of barrier items has increased from 26 to 33, and these are presented in the following categories: Text alternatives & colour, Structure & Navigation, Video & Audio, Forms, Data Tables, and Understandable.

I have also included two new categories:

  • Use of Other Technologies – to accommodate the growing use of third-party components such as social networking tools or ticketing systems, which are often inaccessible.  Sometimes these tools can cause a variety of accessibility issues and the aim of this section is to highlight which tools are the sources of the problems.
  • Device Usability – to meet the need of an increasing number of clients who want to know if their site will work with smart phones and tablets. There is also an item to indicate the overall usability of the site with a screen reader.  I know this may be contrary to the technology neutral (agnostic) approach of WCAG 2.0, but think website owners and developers will find it useful.

New Column for Importance Rank

The original Accessibility Barrier Score calculations (2011) were based only on two factors: How often are page components, which might cause problems, present on the site; and, the severity of those problems as determined by the person using the system to evaluate the site. When calculating the Remediation Priority, the Access Barrier Score system did not take into account how much importance the site owner (or external regulators) gave to a particular issue.

The Accessibility Priority Tool (2013) contains an additional column, “Importance Ranking”, which allows those with overall responsibility for the accessibility of a site to have an influence on how important they believe each barrier to be in relation to their particular circumstances. Each item is given a value of between 1- 5, with 1 being least important and 5 the most.

The intention of the Importance Ranking values is to reflect the overall objective of the site and the needs of the main target audience when determining the priority given to addressing the different identified access barriers.  The importance rank should not be viewed as a proxy for WCAG 2.0 conformance levels. Different organisations will determine the importance ranking for each of the access barriers depending on their circumstances. The ranking values should be entered into the APT worksheet well before an accessibility evaluation of a site is undertaken, thereby enabling the organisation to have an input into the relative importance of the different access barriers that is independent of the objective severity of the barriers as determined by the accessibility evaluator.

The following examples are provided to help explain the aim of the Importance Ranking:

  • A regulator (e.g. a government agency or large institution) may use it to set their overall priorities for the various issues.
  • A client with a site aimed primarily at people who have hearing difficulties might decide to give a higher ranking to the need to provide a sign language alternative for video material when compared, for example, to a site devoted to opera.
  • A site targeted at the elderly may give greater weighting to issues relating to text size and colour contrast, than might be the case with a site for young people.
  • An educational or welfare site specifically for people with reading difficulties may decide to give the highest ranking to several issues that relate directly to their audience, even though in WCAG 2.0 terms these might be at Level AAA.

The Importance Ranking is just a tool for moderating the Access Barrier Advice (column F) calculated for each item. Since the importance rank values will be established by the organisation prior to the accessibility evaluation of a site or sites and not subject to change by those undertaking accessibility evaluations, I expect the Importance Ranking column in the excel worksheet will normally be hidden after it has been set and not displayed during site evaluations or in the in the final results.

The attached APT worksheet Excel file already contains Importance Ranking values for each item. These values are my opinions about how important each issue is, based on my experiences and personal prejudices. For example, I tend to give issues relating to needs of people with cognitive and reading difficulties a rank higher than that suggested by the conformance levels in WCAG 2.0.

If you wish to use the attached excel worksheet but believe some of the Importance Ranking values are not correct or do not reflect your needs please feel free to change them.

How to use the Accessibility Priority Tool

The Accessibility Priority Tool is an Excel worksheet which uses an inbuilt formula to calculate advice relating the potential accessibility issues (Access Barrier Advice) based on the information provided. The aim of the APT worksheet is to provide website owners and developers with a tool to help them prioritise their efforts in correcting issues that may prevent some people from accessing or using the content of the site.

The Excel sheet contains eight columns:

  • Item (number)
  • Description of Access Barrier
  • Reference
  • Incidence score
  • Severity score
  • Access Barrier advice
  • Comments
  • Importance Ranking – which may be displayed or hidden

Within the Description column there are 33 potential barriers to accessing web content, for example “Images without appropriate text alternatives (alt text)” and “Unable to programmatically identify form inputs (e.g. explicitly associated labels or title attribute)”. There are also items relating to the use of third-party page components such as embedded external ticketing systems, and how usable pages are with different devices including screen readers and smart phones.

Preparation: Determining the Importance Ranking (Excel column H – NB sometimes hidden)

Prior to using the Accessibility Priority Tool an importance rank value must be provided in the “Importance Ranking” column for each of the items (with a score of 1 for the least important through to 5 for the most important).

Who determines the importance of the items will depend who is responsible for the accessibility of the site and the circumstances of the accessibility evaluation. The following examples are provided to help explain this point.

  • Government departments and large enterprise such as financial institutions, often have processes and teams for determining and monitoring the quality of websites. Those with overall responsibility for ensuring the accessibility of web content would enter the values into the Importance Ranking column (perhaps with the assistance of an accessibility specialist). In this situation, the importance rank values for various items are likely to be constant for the organisation. Many different people from within (and maybe outside) the organisation will be using APT worksheets with the same importance rankings to evaluate different pages (or page components).
  • At the other end of the scale, there are small not-for-profit organisations without dedicated web teams. In these situations, the Importance Ranking values will need to be determined in advance by the accessibility evaluator consulting with representatives from the organisation and with reference to the objectives and target audience of the site.
  • Some organisations may use the importance ranking as a way to prioritise work based on the native accessibility capabilities within the organisation. For example, basic issues that are easy to address within the organisation could be given a higher priority when compared to more complex issues that might require outside assistance.

The importance ranking (column H) would probably not be displayed in worksheets used by people evaluating the accessibility of the web content because the values would be constant for an organisation, and couldn’t be changed by the people undertaking evaluations. Also the visibility of the importance ranking could influence the impartiality of an accessibility evaluator.

As mentioned earlier, the APT Excel file contains suggested Importance Ranking values for each of the items. However, these values can be changed depending on how important each item is considered in different situations.

Evaluation: Incidence Score (Excel column D)

The Incidence score is a measure of how frequently the person using the tool believes that a particular barrier occurs on the site, or how frequently the way a site component is used does not meet the relevant accessibility requirements.

They enter an Incidence Score for each access barrier item using a five point scoring system:

0 – There is no incidence or occurrence of a failure to make the component accessible.

1 – The use of the page component or element causes access problems up to 25% of the time.

2 – The use of the page component or element causes access problems between 25% and 50% of the time.

3 – The use of the page component or element causes access problems between 50% and 75% of the time.

4 – The use of the page component or element causes access problems more than 75% of the time.

The following examples are provided to help explain the use of the Incidence Score:

  • If there are 10 images in the content being reviewed, and 4 of those images have no alt text (item 1), the lack of a text alternative could cause an accessibility problem 40% of the time images are used, so the incidence score would be 2.
  • If a site has just one CAPTCHA and it is inaccessible (item 5); then 100% of the times CAPTCHA is used could cause a problem, so the incidence score would be 4.
  • If a site contains a number of pages with good content headings and sub-headings that use the correct mark-up, but on one page there are a few sub-headings that don’t use heading elements (item 9), then incidence score for the use of heading elements would be 1.
  • If all the form inputs, which require the correct information to be entered, clearly identify when an error is made (item 28), then the incidence score would be 0
  • However, if between 50% and 75% of the form inputs that identify errors, fail to provide a suggestion for correcting the error (item 29), then the incidence score would be 3

Evaluation: Severity Score (excel column E)

The person undertaking the accessibility evaluation uses the Severity score to rate the likely impact they believe each barrier or page component (column B) will have for someone with a disability.

The impact is rated with a Severity score of 1 to 5, where 1 is a minor inconvenience, and 5 indicates someone would be totally prevented from accessing the site content or functionality. For example:

1. Very minor inconvenience: Not likely to prevent anyone from accessing content, but could be a minor irritant.

2. Minor inconvenience: Not likely to prevent anyone from accessing content, but could affect the ability of some people to use a page.

3. Average inconvenience: Could make it difficult for some people to access content and use a page.

4. Major inconvenience: Could prevent some people from accessing or using page content.

5. Extreme inconvenience: Will prevent access to sections of the site or the ability to perform required functions.

Allocation of the severity rating will of course be subjective, and as such, is always liable to be influenced by the abilities, experiences, knowledge and foibles of the person making the decision.  For example, if we take just three potential barriers that all relate to vision: text alternatives for images; colour contrast; and focus visible, the severity score given to each of these may vary greatly depending on your starting point. If you are solely concerned with the ability of screen reader users to use the web, the failure to include text alternatives is a major potential barrier, where as contrast ratio and focus visible are not barriers at all. On the other hand, if your concern relates primarily to diminished colour vision, contrast ratio and focus visible will be more important than text alternatives. And, for all web users, apart from those who are unable to perceive content visually, a failure to make focus visible is likely to be a significant barrier.

The subjective nature of determining the severity of an accessibility barrier is one of the reasons why I believe it is important for anyone using the suggested Accessibility Priority Tool (or any other process of accessibility evaluation) to have some knowledge of accessibility and assistive technologies.

Access Barrier Advice (excel column F)

When determining the final Access Barrier Advice, the Accessibility Priority Tool uses both the Incidence and Severity scores entered by the accessibility evaluator as well as the Importance Ranking values, which have been previously entered.

The Access Barrier Advice is presented as:

  • None
  • Low
  • Medium
  • High
  • Very High
  • Critical

NB: The Access Barrier Advice generated by the APT worksheet is just a suggestion and should not be solely relied upon. The advice may not accurately reflect the significance of a serious or important issue when the incidence is low. For example, a critical image with a missing text alternative among many (less important) images with good text alternatives will generate a maximum Access Barrier Advice of “High” when in fact it might be very important and critical to the accessibility of the site.

Comments (Excel column G)

This column should be used to provide comments about the relevant accessibility item and highlight examples of the barrier that are likely to have the greatest impact.

The comments column can be used to compensate for the relatively low Access Barrier Advice that can be given to important issues when there is a low incidence (as described above).

Conclusion

The Accessibility Priority Tool outlined in this article aims to provide web content developers and organisations with an Excel tool that will help them identify potential accessibility barriers to content on their sites and prioritise their efforts to address them.

The APT worksheet is a tool, and is not intended to be an alternative to, or replacement for, the Web Content Accessibility Guidelines or any of the WCAG2.0 checklists that are available. Also the tool will only be really effective when it used by people who are knowledgeable about web content accessibility and have experience evaluating the accessibility of sites.

I think this tool may be particularly useful to organisations that have a number of people monitoring the accessibility of sites, since the APT considers both the needs of the organisation and the audience for the site, as well as input from experienced accessibility evaluators, when determining advice relating to each of the potential accessibility barriers. Organisations can then combine this advice with knowledge of their own in-house accessibility capabilities when determining those issues they might be able to address quickly (low-hanging fruit) and those that might take longer and require greater resources.

I have tested the APT Excel worksheet with a variety of hypothetical situations and it seems to work fine apart from scenarios that involve a low incidence of a significant accessibility barrier (as mentioned in this document). For this reason, all the information (Incidence score, Severity score and Comments) provided for each of the access barrier items, and not just the Access Barrier Advice (Column F), should be used when determining remediation priorities.

Update 11 March 2013

As a result of the feedback from Detlev that identified the problem with using decimal points in the Excel formula, the Accessibility Priority Tool Excel file has been corrected, with considerable assistance from Andrew Downie, to remove the decimal point. In the attached APT Priority Tool Excel worksheet, Column ‘I’  is used to calculate the worksheet ‘Access Barrier Advice’ for each item that is presented in Column ‘F’. I have hidden Column ‘I’, but if you unhide it you can see the numerical calculation results.

CSUN 2013

I will be discussing this issue at the CSUN 2013 International Technology and Persons with Disabilities Conference in San Diego in the presentation, Accessibility is more than WCAG Compliance on Wednesday February 27 at 8.00 am.

Since the release of WCAG 2 there has been considerable debate about how to determine the accessibility of websites. Unfortunately, this is often presented as two simple choices: either using a checklist to determine the level of compliance/conformance with the specific Success Criteria; or, undertake some form of user testing by people who have different disabilities and/or who rely on different assistive technologies.

During this presentation I will look at the advantages and disadvantages of these two approaches. I will also report on the results of using the Access Barrier Scores during 2012 and the development of the Accessibility Priority Tool described in this article.

Headings: Who needs ’em?

by
, , ,

This is a story about web page headings and sub-headings: A story that tries to look beyond the absurd distinctions that are sometimes made about the usability and accessibility of web content, to ask who needs headings and why.

Imagine, if you will, a web page containing a 5,000 word article; a large slab of text with many sentences and paragraphs.  Most, if not all, people will find this article easier to read if it is broken up into sections, each identified with an appropriate heading or sub-heading, and for people with disabilities it can be especially important. This is the starting point for our discussion of web content usability and accessibility.

WCAG 2.0 – usability and accessibility

The launch of the first Mosaic browser in 1993 could be considered the beginning of the mass consumption, commercial web as we know it today. The release of the W3C Web Content Accessibility Guidelines (WCAG 1.0) six years later in 1999, highlighted the importance of making sure this fantastic new communication medium was accessible to all, as encapsulated in this oft quoted comment by W3C Director Tim Berners Lee, “The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Version 2 of the Web Content Accessibility Guidelines (WCAG 2.0) was released at the end of 2008. Two guiding principles during the development of WCAG 2.0 were the need to have guidelines that could be applied to different web technologies, and the need for rules (Success Criteria) that could be reliably tested by machines and/or human evaluators with relative ease.  This desire for a more accurate system of compliance testing meant that the inevitable blurring of the boundary between usability and accessibility was avoided as far as possible when framing WCAG 2.0. “There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2.0, we only include those guidelines that address problems particular to people with disabilities.” [Understanding the Four Principles of Accessibility]

WCAG 2.0 has three levels of conformance for Success Criteria; ‘A’, ‘AA’ or ‘AAA’, and at least all level ‘A’ success criteria must be complied with before a site can claim conformance with WCAG 2.0. Many governments and organisations concerned with the accessibility of web content now use WCAG 2.0 as the benchmark, requiring all sites under their jurisdiction to conform at a specific level, for example, the Australian Human Rights Commission advocates sites “comply with WCAG 2.0 to a minimum of AA-Level conformance”.

Unfortunately, in the push for accessibility purity by WCAG 2.0, most issues with a taint of usability were pushed into Level AAA, and even the W3C advises, “It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content”. [WCAG 2.0 Conformance Requirements]

(It should be noted, WCAG 2.0 Success Criteria levels are not direct equivalents to the WCAG 1.0 Priority levels.)

Headings and WCAG 2.0

When it comes to our imagined 5,000 slab of words, there are, as far as I can see, three success criteria that relate directly to use of headings and sub-headings:

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

2.4.10 Section Headings: Section headings are used to organize the content. (Level AAA)

The usability of a 5,000 word article for all web users is likely be improved by presenting the information in a number of sections each identified with a heading. Furthermore, the article content will be more accessible to people with a range of disabilities, including some with cognitive and/or learning difficulties as well as people who rely on screen readers to access the web. However, the basic requirement to organise web content into sections is at Level AAA, and so failing to break up our large slab of text with headings would not, in itself, result in a failure to comply with the WCAG Level A or Level AA requirements of most jurisdictions.

What happens at the other end of the compliance spectrum also appears to be interesting in an absurd sort of way. It seems to me that it is possible to comply at Level A with meaningless headings and sub-headings, so long as they use the correct HTML heading mark-up.

What! You might shriek. Well, let me explain. Say our 5,000 word article is presented in sections, each identified with generic heading text that literally uses some meaningless words like ‘heading’ or ‘sub-heading’, but marked up appropriately (i.e. <h1>heading</h1> … <h2>sub-heading</h2> etc). This would appear to comply at Level A (success criterion 1.3.1), since to quote Understanding WCAG 2.0, “The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.” [Understanding Success Criteria 1.3.1]. Or to put it another way, the information available through presentation is also being conveyed programmatically. The screen reader user, like everyone else would know, for example, that something called ‘heading’ is a main heading at H1, and at a lower level in the hierarchy there are items called ‘sub-heading’ at H2. Clearly, headings such as these would be a kind of visual pollution and meaningless to everyone, but the requirement for headings to actually describe a topic or purpose is at Level AA.

As with Goldilocks, something in the middle seems to be just right. At Level AA, headings need to be meaningful, and since a page can’t comply at AA without complying at A, this meaningfulness needs to be programmatically determinable. Meaningful headings will be easier for everyone to understand and will help those who have problems reading to locate the information they are seeking. And for screen reader users, as we should all know by now, HTML heading elements are a vital tool, since it allows them to easily identify, locate and navigate to different sections of a web document.

Of course with our 5,000 word slab of sentences and paragraphs, this middle AA path will only apply if the site author thought to include headings at all. And if they didn’t, people with cognitive disabilities and reading difficulties are likely to be among those who will suffer the most, because meeting their specific accessibility need for meaningful headings, and several other issues, is a Level AAA concern, and so easily ignored.

CSUN 2013

Roger Hudson will consider different aspects of this issue in two presentations at the CSUN 2013 International Technology and Persons with Disabilities Conference in San Diego.

Accessibility is more than WCAG Compliance: Wednesday February 27 at 8.00 am (ouch).

The Forgotten of Web Accessibility: Wednesday February 28 at 9.20 am.