Accessible forms using WCAG 2.0
accessibility, video, WCAG 2.0
“Accessible Forms using WCAG 2.0” is the first of a series of documents to help web professionals use the Web Content Accessibility Guidelines Version 2.0 to develop accessible websites.
This document aims to provide web developers and others with practical advice about the preparation of accessible HTML forms. It compares the WCAG 1.0 accessibility requirements relating to forms with those contained in WCAG 2.0.
I wish to thank Chris Bentley, Andrew Downie and Russ Weakley for their considerable knowledge and assistance in preparing this document.
NB: This document is a work-in-progress. Please send feedback and any suggestions about errors and omissions to rhudson@usability.com.au
Introduction
Web Content Accessibility Guidelines Version 1.0 (WCAG 1.0) is primarily concerned with advocating the use of W3C Technologies such as HTML and CSS to prepare accessible websites. Version 2.0 of the Guidelines is technology neutral. That is, WCAG 2.0 does not explicitly relate to the use of HTML but is concerned with improving the accessibility of sites regardless of the technologies used.
As part of this new approach, WCAG 2.0 incorporates the notion of “accessibility supported technologies” defined as:
“An accessibility supported technology is a technology (HTML, CSS, etc.) that will work with assistive technologies (AT) and the accessibility features of browsers and other user agents. Only technologies (including features of the technologies), that are “accessibility supported” can be used to conform to WCAG 2.0 Success Criteria.”
Although there is no list of recognised “accessibility supported technologies”, it is expected that all W3C technologies and common non-W3C technologies (e.g. JavaScript and Flash) when used appropriately will be considered accessibility supported.
WCAG 2.0 is built around 4 basic principles. Within these principles, there are 12 Guidelines which contain a total of 61 “testable” Success Criteria. Each Success Criteria is assigned one of three defined levels of conformance: A (lowest), AA, AAA (highest).
For each Success Criteria, the WCAG Working Group has provided “Sufficient Techniques” which they have deemed to be sufficient for satisfying the Success Criterion.
The Web Accessibility Initiative (WAI) has released the following primary WCAG 2.0 documents:
- Candidate Recommendation of WCAG 2.0″ (30 April 2008)
- How to Meet WCAG 2.0″ reference document (30 April 2008), which contain suggested techniques for each Success Criteria
- Understanding WCAG 2.0″ (30 April 2008)
The various forms presented in this document have been tested will the following screen readers JAWS 7.1, JAWS 9 and Window-Eyes 6.1.
Forms: Accessibility and Assistive Technologies
Forms can present problems for web users with vision and/or mobility impairment and for people with cognitive or learning disabilities. Someone with impaired vision who relies on an assistive technology such as a screen reader with audio and/or Braille output can easily get lost in a badly made form. For these devices to work effectively, the technology needs to be able to associate a form label (request or prompt) with the correct form control, such as a text field or checkbox.
Many people with vision and mobility disabilities interact with the web (and forms) using primarily the keyboard rather than a mouse. As a result their interactions tend to be sequential with the sequence order largely controlled by the way the page has been designed.
Screen readers allow users to interact with a web page in a variety of ways. As a default, screen readers will sequentially read the content of the page; with JAWS this is called “Virtual PC Cursor” mode and with Window Eyes it is called “Browse Mode”. For convenience, this document will refer to this default mode of access as “Read” mode. Using Read mode, users can quickly locate a form on a page and scan its content.
When the user needs to enter text into the form, they must use the keyboard to turn the Virtual Cursor off and in JAWS parlance switch to “Form” (input) mode. With Window Eyes the user must switch to “Browse Off ” mode. This will be called “Form” mode in this document.
In Form mode, the user is basically restricted to moving between elements on the page that can accept focus (eg form inputs and links) and this means that if they need to read surrounding material such as paragraphs or headings they have to go out of Form mode.
Form Input Labels
Two WCAG 1.0 Checkpoints relate directly to the use of labels for forms:
“Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels ensure that the label is properly positioned.” [Priority 2]
WCAG 1.0 Checkpoint 10.2
“Associate labels explicitly with their controls. For example, in HTML use LABEL and its “for” attribute.” [Priority 2]
WCAG 1.0 Checkpoint 12.4
Combined these two checkpoints, when read in conjunction with the HTML 4.01 specification, appear to require all form inputs to have a label that is correctly positioned and explicitly associated with the control (input).
None of the WCAG 2.0 Success Criteria directly mention HTML or forms. However, the following two Success Criteria are concerned in part with identifying form controls.
“Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.” (Level A)
WCAG 2.0 Success Criteria 1.3.1
“Labels or Instructions: Labels or instructions are provided when content requires user input.” (Level A)
WCAG 2.0 Success Criteria 3.3.2
Success Criteria 1.3.1 and 3.3.2 both contain the following Sufficient Techniques (HTML):
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)
Explicit association
Sufficient Technique H44 is very similar to WCAG 1.0 Checkpoint 12.4 in that it requires form labels to be explicitly associated with their controls.
Explicit association means that the HTML element “label” with the “for” attribute, and the input attribute “id” should be used to associate a text or graphic label with a specific form control. The attributes can be used with nearly all input elements, including text boxes, checkboxes and radio buttons, textarea and select. However, the “id” attribute for each element (radio button, text etc) in a document must be unique.
Simple form showing appropriate position of labels:
Form 1: Correct position and explicit association of labels
The following excerpt of code for the form above uses “label for” and “id” to explicitly associate the text input and radio buttons with their labels.
HTML
<form action="#" method="post"> <div> <label for="nm">Name: </label> <input id="nm" type="text" name="name" value=""> </div> <div> <input id="yes" name="request" value="yes" type="radio"> <label for="yes">Yes</label> <input id="no" name="request" value="no" type="radio"> <label for="no">No</label> </div> </form>In Read mode, the JAWS screen reader will present the simple form above like this:
Name colon, name colon edit. Radio button not checked, yes. Radio button not checked, no.
When you switch to Form mode the form is presented like this:
Name colon edit, type-in-text. Yes radio button not checked. One of two, to change the selection press up or down arrow keys.
Another benefit of explicitly associating a label with its control (input) is an increase in size of the area that can be clicked to access the input. This is particularly helpful for people with diminished vision or fine motor skill difficulties, but who are still able to use a mouse. With a text input (like the name example above) clicking anywhere on the label or textbox will put the cursor at the beginning of the text input area. Similarly, a radio button or checkbox can be checked by clicking either the label or button (or box).
NOTE: The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button).
- Submit and Reset buttons (input type=”submit” or input type=”reset”)
- Image buttons (input type=”image”)
- Hidden input fields (input type=”hidden”)
- Script buttons (button elements or <input type=”button”>)
Source: WCAG 2.0 Technique H44:
Title attribute
When it comes to identifying form controls, one of the most significant advances with WCAG 2.0 is Sufficient Technique H65 that allows the form control title attribute to be used for this purpose, “when the visual design cannot accommodate the label or where it might be confusing to display a label”.
For design reasons, the site-search form input field at the top of pages on some sites are presented without a label. In order to fully comply with WCAG 1.0, some developers have provided a non-visible label for these search inputs by using the CSS “off left” technique to remove the label from the display area while still allowing it to be accessed by screen readers. With WCAG 2.0, the use of the form control title attribute is deemed a Sufficient Technique.
Form 2: Site-search form input without label
When no label is provided for a form control, as in the example above, some screen readers will automatically associate the immediately preceding piece of text with the control. With the example above, this could lead some screen reader users to believing that the input relates to searching for information just about employment issues.
However, when no label is present and the title attribute for the form control (text input field) is used, recent versions of both JAWS and Window-Eyes will present the title attribute when the form control receives focus.
HTML
<div id="global"> <ul> <li><a href="#">About us</a></li> <li><a href="#">Services</a></li> <li><a href="#">Employment</a></li> </ul> <form method=get id="searchform" action="/search.php"> <div> <input type="text" title="site search" name="query" id="q" value=""> <input type="submit" value="search"> </div> </form> </div> Sometimes, forms need to provide information that relates to a following question. When this information is presented as a heading, or sentence/paragraph as in Form 3 below, it will not be presented by the screen reader when it is in Form mode. One way of ensuring this information is presented in Form mode is to use the information as the “legend” within a “fieldset”. (See later section, Grouping Form Elements.)
Since use of the title attribute to identify a form control is a Sufficient Technique in WCAG 2.0 this provides another potential way of addressing this issue.
Form 3: Form with radio buttons that use title attributes
HTML
<form action="#" method="post"> <div> <label for="name">Name: </label> <input id="name" type="text" name="name" value=""> </div> <div> <label for="email">Email: </label> <input id="email" type="text" name="email" value=""> </div> <p> Choose a subscription option from below: </p> <div> <input id="Weekly" title="weekly subscription" name="subscribe" value="Weekly" type="radio"> <label>Weekly</label> <input id="Monthly" title="monthly subscription" name="subscribe" value="Monthly" type="radio"> <label>Monthly</label> <input id="Quarterly" title="quarterly subscription" name="subscribe" value="Quarterly" type="radio"> <label>Quarterly</label> </div> </form>When the form above is presented by JAWS in Read mode, the instruction, “Choose a subscription option from below” followed by the radio buttons is presented as follows:
“Choose a subscription option from below colon.”
“Radio button not checked weekly subscription. Weekly”
“Radio button not checked monthly subscription. Monthly”
“Radio button not checked quarterly subscription. Quarterly”
In Form mode the instruction paragraph is not read. However, the aim of the radio buttons is clearly communicated by screen reader presenting the title attribute for each of the radio buttons as follows:
“Weekly subscription radio button not checked; One of three. To change the selection press up or down arrow. [Press down arrow]”
“Monthly subscription radio button checked; two of three. To change the selection press up or down arrow. [Press down arrow]”
“Quarterly subscription radio button checked; three of three. To change the selection press up or down arrow”
Window Eyes also effectively presents the title attribute in both Read and Form modes, although Window Eyes does generally tend to use fewer words.
It worth mentioning that with both JAWS and Window Eyes, it is not necessary to switch to Form mode (that is turn off the Virtual cursor or Browser mode) in order to make a radio button or checkbox selection.
VIDEO 1: Screen reader reporting of explicit association and title attribute
Form controls in data tables
Some data tables contain form inputs that can be used to enter information. For example a form for ordering quantities of different products or a form for depositing money in different accounts as shown in the simplified example below.
Form 4: Data table containing form text input fields
The inclusion of a label for each of the form inputs, which can be used to enter information in the table above, is both unnecessary and redundant. Under WCAG 2.0, the use of the title attribute, as shown in the code excerpt below, would be a Sufficient Technique and would probably be the most feasible approach in situations like this.
HTML
<form action="#" method="post"> <table summary="form for allocating deposits to different accounts"> <caption><strong>Deposit form</strong></caption> <thead> <tr> <th>Account name</th> <th>Account balance</th> <th>Deposit amount</th> </tr> </thead> <tbody> <tr> <th>Personal savings</th> <td align="center">$1,200.00</td> <td align="center"><input type="text" title="deposit amount for personal savings" value=""></td> </tr> <tr> <th>Investment account</th> <td align="center">$2,200.00</td> <td align="center"><input type="text" title="deposit amount for investment account" value=""></td> </tr> <tr> <th>Holidays</th> <td align="center">$3,200.00</td> <td align="center"><input type="text" title="deposit amount for holidays" value=""></td> </tr> </tbody> </table> </form>When the “Deposit form” above is accessed by JAWS in Read mode, the screen reader identifies a cell containing the form input and presents the control title attribute as follows:
Deposit amount for personal savings, edit.
If the user wishes to make an entry into a particular form field, they will then need to switch to Form mode. The JAWS screen reader will then present the title attribute of each input as the user tabs through the form:
Deposit amount for personal savings edit, type-in-text. [tab]
Deposit amount for investment account edit, type-in-text. [tab]
Deposit amount for holidays edit, type-in-text.
When the “Deposit form” is accessed with Window Eyes a very similar thing occurs.
Video 2: Showing how screen readers report the deposit (data table) form above
Grouping Form Elements
A form where different elements are well organised with similar ones grouped together is easier for everyone to use. Grouping form elements together can be particularly helpful for people who depend on screen readers and for those with cognitive or learning disabilities.
Under WCAG 1.0, Checkpoint 12.3 advocates the use of the HTML elements “fieldset” and “legend” for this purpose.
“Divide large blocks of information into more manageable groups where natural and appropriate. For example, in HTML, use OPTGROUP to group OPTION elements inside a SELECT; group form controls with FIELDSET and LEGEND; use nested lists where appropriate; use headings to structure documents, etc.” [Priority 2]
WCAG 1.0 Checkpoint 12.3
In WCAG 2.0, Success Criteria 1.3.1 contains the following three Sufficient Techniques which fundamentally address the same issue:
H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
H82: Grouping form controls with FIELDSET and LEGEND (HTML)
H85: Using OPTGROUP to group OPTION elements inside a SELECT (HTML)
“Fieldset” and “legend”
The HTML elements “fieldset” and “legend” allow forms with different areas of interest to be organised in a logical way. As a default, the “fieldset” element will create a box around the selected section and the “legend” will be in bold. In this way, form elements can be grouped together into identified categories. For example:
HTML
<fieldset> <legend> Personal Details</legend> <div> <label for="name">Name:</label> <input id="name" type="text" name="name" size="30"> </div> <div> <label for="idnum">ID Number:</label> <input id="idnum" type="text" name="id number" size="20"> </div> </fieldset>Different browsers may display the default “fieldset” border in different way. Cascading Style Sheets can be used to remove the border or change its appearance.
Most screen readers will identify the different items within a “fieldset”. In ‘Form’ mode JAWS reports the value of the “legend” before the label for each control contained within the “fieldset”. The Personal Details form above is presented by JAWS in ‘Form’ mode like this:
Personal details, name colon edit, type-in-text
Personal details, ID number colon edit, type-in-text
Window Eyes identifies when a “fieldset” starts and ends and reports the “legend” at the beginning of the “fieldset”.
Nested “fieldset”
A “fieldset” can be nested inside another “fieldset”. For example:
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. For example, when an extra form control is presented after a nested “fieldset” as shown above, some screen readers will associate the preceding “legend” with the extra form control rather than the “legend” of the parent “fieldset”.
JAWS 7.1 in Form mode for example, reports the form with a nested fieldset shown above like this:
Participant, name colon edit, type-in-text [tab]
Areas of interest, writing checkbox not checked. To check press spacebar [tab]
Areas of interest, drawing checkbox not checked. To check press spacebar [tab]
Areas of interest, painting checkbox not checked. To check press spacebar [tab]
Areas of interest, pottery checkbox not checked. To check press spacebar [tab]
Areas of interest, companion colon edit, type-in-text
NOTE: The form label “Companion” is presented with the legend “Areas of interest”.
Video 3: Screen reader reporting of fieldset and legend
JavaScript
In general, WCAG 1.0 did not consider JavaScript universally accessible and required web pages to work without JavaScript support.
“Ensure that pages are usable when scripts, applets etc are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.”[Priority 1]
WCAG 1.0 Checkpoint 6.3
When JavaScript was used, it had to be directly compatible with assistive technologies and not use device-dependent event handlers.
“Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.”[Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2]
WCAG 1.0 Checkpoint 8.1
“For scripts, specify logical event handlers rather than device-dependent event handlers.” [Priority 2]
WCAG 1.0 Checkpoint 9.3
A significant number of online forms however use JavaScript. Since most assistive technologies now support JavaScript when it is used appropriately, and most users of these technologies access the web with browsers and devices that are JavaScript enabled, the use of JavaScript per-se is no longer likely to cause significant accessibility problems.
Since WCAG 2.0 is designed to be technology neutral none of the Success Criteria relate specifically to the use of JavaScript. However, there are 5 Conformance Requirements that must be met in order for content to be classified as “conforming” to WCAG 2.0.
Conformance Requirement 4 states:
“Accessibility-Supported Technologies Only: Only accessibility supported technologies are relied upon to satisfy the success criteria. Any information or functionality that is implemented in technologies that are not accessibility supported are also be (sic) available via technologies that are accessibility supported.”
Understanding Conformance (WCAG 2.0)
When it comes to the use of JavaScript with forms, the following Techniques, which are supported by modern browsers and screen readers, may be useful:
“Providing client-side validation and alert: To validate user input as values are entered for each field, by means of client-side scripting. If errors are found, an alert dialog describes the nature of the error in text.”
“SCR19: Using an onchange event on a select element without causing a change of context: The objective of this technique is to demonstrate how to correctly use an onchange event with a select element to update other elements on the Web page. This technique will not cause a change of context.”
“SCR21: Using functions of the Document Object Model (DOM) to add content to a page: The objective of this technique is to demonstrate how to use functions of the Document Object Model (DOM) to add content to a page instead of using document.write or object.innerHTML. This technique is useful for inserting error messages at the top of a form.”
For more information and techniques see the W3C Full list of Client-side Scripting Techniques for WCAG 2.0
Error Detection and Messages
WCAG 1.0 did not contain any guidelines that were directly concerned with the prevention and correction of errors. Addressing this issue with the following specific Guideline is one of the significant advances with WCAG 2.0:
“Guideline 3.3 Input Assistance: Help users avoid and correct mistakes”
This Guideline contains the following six Success Criteria that relate directly to error prevention, detection and correction:
“Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.”
WCAG 2.0 Success Criteria 3.3.1 (Level A)
“Labels or Instructions: Labels or instructions are provided when content requires user input.”
WCAG 2.0 Success Criteria 3.3.2 (Level A)
“Error Suggestion: If an input error is detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.”
WCAG 2.0 Success Criteria 3.3.3 (Level AA)
“Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.”
WCAG 2.0 Success Criteria 3.3.4 (Level AA)
“Help: Context-sensitive help is available.”
WCAG 2.0 Success Criteria 3.3.5 (Level AAA)
“Error Prevention (All): For Web pages that require the user to submit information, at least one of the following is true:” (Same as for 3.3.4)
WCAG 2.0 Success Criteria 3.3.6 (Level AAA)
The W3C provides many “Sufficient Techniques” and “Advisory Techniques” to help developers prepare forms that comply with the Success Criteria for 3.3: Input Assistance.
Techniques for Guideline 3.3 to Help Users Avoid and Correct Mistakes
Developers could find the following Sufficient Techniques, which are supported by modern browsers and screen readers, useful:
G83: Providing text descriptions to identify required fields that were not completed.
SCR18: Providing client-side validation and alert.
G85: Providing a text description when user input falls outside the required format or values.
G139: Creating a mechanism that allows users to jump to errors.
SCR21: Using functions of the Document Object Model (DOM) to add content to a page.
In general, when validation detects errors in a form, there is a 4-step process for ensuring usable and accessible error recovery:
- Alert the user to the presence of an error in an accessible manner
- Provide advice on how the error can be corrected
- Allow the user to easily access the form elements that need to be rectified
- Allow re-submission and re-validation of the form
Avoid using organisational jargon or code for error messages.
The following form provides a suggestion for how error messages may be presented in a useful and accessible way:
Form 7: Identifying errors and providing assistance
Form 7a: Identifying errors and providing assistance
The “Error Detection and Messages” form uses client-side JavaScript to identify an error (for example failure to fill in the second number) and provide a description of the error at the top of the page. The error description is a link, which when activated moves the cursor (focus) to the matching form control so that the user can easily make the necessary correction.
The source code for Form 7 Error Detection and Messages contains the required CSS, JavaScript and HTML for the form.
This form works with recent versions of JAWS and Window Eyes. However, since a few people access the web with devices that do not support JavaScript, developers should ensure client-side error detection fails gracefully in circumstances where JavaScript support is not available or has been rendered inactive. This will include the provision of back-up server-side checking, which is equivalent to the client-side service, for users who do not have JavaScript.
Video 4: Error detection and message form
Self Populating Selection Options
Some forms contain several drop-down combo menus that use select elements, and the choice made in one menu determines what is presented in a following menu. This issue is addressed in Guideline 3.2 of WCAG 2.0
Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes.
WCAG 2.0 Success Criteria 3.2.5 (Level AAA)
Success Criteria 3.2.5 covers a number of issues, with Sufficient Techniques for each. In relation to the use of select menus that dictate the content of other menus the following Sufficient Technique is provided:
SCR19: Using an onchange event on a select element without causing a change of context
The following example contains two Select elements, “Region” and “Country”. When a Region is selected, for example Asia-Pacific, the Country choices for that region become available. If another Region is selected (eg Europe) then the Country choices are automatically updated to those that relate to the new Region.
Form 8: Form with updating Select element
Form 8a: Form showing second Select element choices
JavaScript is used to allow the choices available in the second Select element to be dynamically determined by the first Select element choice.
This form works with recent versions of JAWS and Window Eyes. The source code for Form 8 JavaScript and Select Menus contains the required CSS, JavaScript and HTML for the form.
NB: Since some people access the web without JavaScript support, it is advisable to provide an accessible alternative way of obtaining the information that is available via this type of form.
Video 5: Form with dynamically updating Select
Show/Hide Form Sections
With multi-faceted forms it is sometimes useful to only show the relevant areas of the form. Banks and other financial institutions often have forms that contain a number of variables and the information the user is required to provide depends on which variable the user selects: For example, do you want a housing or personal loan? Or, do you wish to insure your car or boat?
There are considerable usability and accessibility benefits in providing the user only with the form fields that are relevant to their request. This can be particularly useful for people with cognitive disabilities and learning difficulties.
A combination of CSS and JavaScript can be used to show and hide different sections of a form. However care has to be taken to ensure newly shown form sections are available to screen reader users, while also stopping the screen reader from returning to the top of the page when a new section is presented. By default, when a page refreshes the screen will start reading from the top of the page.
This issue is dealt with in the following Sufficient Technique which relates to three Success Criteria:
SCR26: Inserting dynamic content into the Document Object Model immediately following its trigger element
The W3C provides the following description of this technique:
“This technique inserts new content into the DOM immediately following the element that was activated to trigger the script. The triggering element must be a link or a button, and the script must be called from its onclick event. These elements are natively focusable, and their onclick event is device independent. Focus remains on the activated element and the new content, inserted after it, becomes the next thing in both the tab order and screen-reader reading order.
Note that this technique works for synchronous updates. For asynchronous updates (sometimes called AJAX), an additional technique is needed to inform the assistive technology that the asynchronous content has been inserted.”
The following form contains a show/hide section which is determined by the radio button selection. If “cone” is selected the choice of cone sizes is presented. However, if “tub” is selected the “cone” size section is not presented.
Form 9: Show/hide form with Show section displayed
This form works with recent versions of JAWS and Window Eyes. The source code for Form 9 Show-hide contains the required CSS, JavaScript and HTML for the form.
Video 6: Form with a show-hide section
Timed Responses
Some forms have timeouts associated with them. For example, online transactions often use forms where a cookie or server-side variable is set to expire after a designated time or as the result of a period of inactivity.
Completing a form often requires the site user to carry out a number of separate tasks that involve reading and understanding instructions, making choices and then taking the appropriate action.
The setting of time limits for forms is likely to exclude some users with certain disabilities from completing the form in the required time. Where the imposition of a timeout period is not essential it should be avoided.
It is likely that people with cognitive disabilities and learning difficulties will take longer to read and understand written information. Also, it usually takes longer for users who rely on assistive technologies such as screen readers and input switches to access information on a web page and interact with forms.
This needs to be taken into consideration when setting server timeout limits and is specifically addressed in WCAG 2.0.
“Timing Adjustable: For each time limit that is set by the content, at least one of the following is true:
Turn off: The user is allowed to turn off the time limit before encountering it; or
- Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- 20 Hour Exception: The time limit is longer than 20 hours.”
WCAG 2.0 Success Criteria 2.2.1 (Level A)
Success Criteria 2.2.1 contains the following “Sufficient Techniques” that developers might find useful:
SCR16: Providing a script that warns the user a time limit is about to expire: The objective of this technique is to notify users that they are almost out of time to complete an interaction and provide a mechanism to request more time.
SCR1: Allowing the user to extend the default time limit: The objective of this technique is to allow users to extend the default time limit.
G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit. The objective of this technique is to minimize the risk that users will lose their work by providing a checkbox to request additional time.
The W3C advises, Success Criterion 2.2.1 “should be considered in conjunction with Success Criterion 3.2.1 which puts limits on changes of content or context as a result of user action.”
Mandatory fields
Many forms contain input fields that the user must complete. All users, including those with disabilities, should be able to easily determine which fields are mandatory, or required.
Colour alone should not be used to indicate mandatory fields. This issue is addressed in Success Criteria 1.4.1 (Use of Color) with the following Sufficient Techniques:
G122: Including a text cue whenever color cues are used
G14: Ensuring that information conveyed by color differences is also available in text
Often a symbol or the word “required” is used to indicate a field is mandatory. The symbol or word should be presented with the form control label, and inside the label element. It should not be presented after the form control (input).
When a symbol is used, the key to the symbol should be presented before the form and not at the bottom of the form.
Colours and Fonts
Some people with vision disabilities are unable to discriminate between certain colours or may not be able to distinguish text from its background if there is insufficient contrast between the two. In general, use colour very sparingly with forms, and if used there should be considerable difference in contrast between the text and the background.
In WCAG 2.0 the minimum requirement of ensuring sufficient contrast is Success Criteria 1.4.3:
“Contrast (Minimum): Text and images of text have a contrast ratio of at least 5:1, except for the following:
- Large Print: Large-scale text and large-scale images of text have a contrast ratio of at least 3:1;
- Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.”
WCAG 2.0 Success Criteria 1.4.3 (Level AA)
The following Sufficient Techniques are provided for this requirement:
Situation A: text is less than 18 point if not bold and less than 14 point if bold
G18: Ensuring that a contrast ratio of at least 5:1 exists between text (and images of text) and background behind the text
G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults
Situation B: text is as least 18 point if not bold and at least 14 point if bold
G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text
G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults
NB: WCAG 2.0 use a different algorithm to that used in WCAG 1.0 for determining the differences between foreground and background colours.
Also, some users find the default font size on websites is often too small for comfortable reading. This only becomes a major problem if the user is unable to increase the font size with their browser, so relative font size attributes should always be used. With forms, you need to ensure that when the font size is increased in this way the text and different elements don’t overlap.
This issue is addressed in the Sufficient Techniques for Success Criteria 1.4.4:
Resize text: Text (but not images of text) can be resized without assistive technology up to 200 percent without loss of content or functionality.
WCAG 2.0 Success Criteria 1.4.4 (Level AA)