Snap Web Accessibility Guidelines - W3C
Document last modified May 2005, © Snap Surveys, www.snapsurveys.com
Return to Accessibility Overview
1. Introduction
This document is concerned with version 1.0 of the guidelines which are published by the World Wide Web Consortium (W3C). The guidelines can be found at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
The normal version of Snap web questionnaires are able to satisfy all priority 1 (or level 'A') checkpoints, and can also satisfy priority 2, depending upon the content required. In order to produce questionnaires at higher levels of compliance it is necessary to select publication options for an additional 'plain text' version. The plain text version, when published with all of the available options will be compliant with the guidelines to all priority 3 checkpoints - that is level 'AAA' compliance.
This document comprises:
2. Snap Accessibility Options
A summary of the accessibility options available when producing Snap web questionnaires and how each affects accessibility.
3. W3C Guidelines
A listing of the W3C accessibility guidelines, listed with summaries of how Snap supports each checkpoint.
4. Cross reference by priority
A summary of the W3C checkpoints, sorted by priority, with information about which versions of Snap's web questionnaires support each checkpoint.
2. Snap Accessibility Options
This section gives a summary of the accessibility options available when producing Snap web questionnaires and how each affects accessibility.
Inserted Objects
Snap allows various objects to be inserted into the text of questionnaires and some of these have implications for usability.
Images
Authors can provide ‘alt text’ for any Inserted images. This text appears as a tooltip over the image and can be read aloud by screen readers to help people who cannot see the image.
Authors should endeavour to provide meaningful text for all images which they insert (checkpoint 1.1).
Care should be taken to ensure that images are of sufficient contrast (checkpoint 2.2), and that no blinking, flashing or movement be introduced (checkpoint 7.1 , 7.2 , 7.3).
Images can sometimes be used to make content easier to understand (checkpoint 14.2).
Html Web Links
Authors can insert web links into web questionnaires. They should ensure that the link text is easy to understand (checkpoint 13.1).
The static versions of Snap web questionnaires always open links in the same window, in accordance with checkpoint 14.2. Dynamic surveys must open links in a new window due to the way that they work.
Custom Html
Virtually any HTML can be inserted into Snap questionnaires as custom HTML objects. These can be used to implement some accessibility features, such as to mark up changes in language (checkpoint 4.1) or to denote acronyms (checkpoint 4.2).
Care must be taken when using custom HTML as it is possible to introduce features which fail many of the checkpoints in this way.
Plain Text Version
Normal and Plain versions
Snap can optionally produce two versions of each web questionnaire.
The normal version fully implements all dynamic content of a questionnaire, but cannot satisfy all web accessibility guidelines. In particular the use of scripting to provide dynamic content prevents them from satisfying the requirement to function in the absence of scripting (checkpoint 6.3).
The plain text version has many options which can allow full compliance with the W3C guidelines, but cannot support many of the advanced features of Snap dynamic questionnaires.
The two versions are built at the same time and hyperlinks can be added to navigate between the two versions.
The plain version of a survey is named by using the access name followed by ‘_t’, for example if the main version is called ‘survey.htm’, then the plain version will be called ‘survey_t.htm’.
Dynamic Content
The normal version of Snap questionnaires will sometimes contain dynamic behaviour. Such behaviour includes allowing the use of multiple pages, the use of routing, ensuring that responses are given, ensuring that responses are valid, using code rotation, grid rotation and using text substitution of responses.
Dynamic surveys are published as a collection of three files e.g. ‘survey.htm’, ‘surveyB.htm’, ‘surveyC.htm’.
Such surveys cannot satisfy as many of the accessibility guidelines as static questionnaires and it is recommended that a plain text version is produced along side dynamic surveys.
Style Sheets
Using External style sheets
It is possible to produce external style sheets for use with Snap's web questionnaires. They can be produced for all versions, or they can be produced just for the plain text version.
Style sheets enable several guidelines to be met, including the requirement to not use markup for visual formatting (checkpoint 3.3), to avoid deprecated markup (checkpoint 11.2) and to produce formally valid HTML (checkpoint 3.2).
Style sheets make it easier for respondents to reformat the questionnaire in a style which is easier for them to read or navigate.
Style sheets are always updated when new versions of the web questionnaire are produced, and care should be taken to upload the latest version of all files to the host web site.
A style sheet is produced for each of the normal and plain versions, and share the name of the main file, e.g they might be called ‘survey.css’ and ‘survey_t.css’ respectively.
Plain Text Options
Link to file
When both plain and normal versions are produced, web links can be added to the top of each file to allow navigation between versions.
A link to the plain text version from the normal version is required by checkpoint 11.4.
The link text which is chosen should be clear and unambiguous (checkpoint 13.1).
Use no colour
It is possible to automatically remove all colour from the plain text versions.
Whilst it is perfectly possible to produce accessible web pages that use colour, some authors may prefer to produce a colourless version when their main design has low contrast, or is otherwise difficult to read because of the colour scheme (checkpoint 2.2).
Use no images
It is possible to automatically remove all images from the plain text version.
Some authors may prefer to remove images from the accessible version of a questionnaire when patterned backgrounds make a page harder to read (checkpoint 2.2), or when animated GIFs cause problematic visual effects (checkpoint 7.1 , 7.2 , 7.3).
Note that the use of images normally causes no accessibility problems, and the use of graphics is even recommended in cases when they add to understanding (checkpoint 14.2), provided that text alternatives are provided (checkpoint 1.1).
Use strict rules
The plain text version of web questionnaires in Snap can have a set of strict accessibility rules applied.
The use of all of these rules ensures maximum accessibility for the plain text version.
Some of the rules fundamentally modify the appearance of the questionnaire, whilst others increase the size of the file produced. For these reasons the rules are not available for the normal version.
Note that strict rules are not required for priority one compliance.
The strict rules are described in more detail in the following section.
Using Strict Rules
Position labels correctly (priority 2)
This rule ensures that checkboxes are arranged in a single column (checkpoint 10.3), and that the code labels are placed to the right of the checkbox (checkpoint 10.2). Similarly, labels for open response controls are constrained to be either to the left or above their control.
This rule helps screen readers to correctly associate each label with the correct control in situations where there is no support for explicit labelling. Note that Snap always associates labels explicitly using the <label for=> mechanism.
Expand grids (priority 2)
Grid questions containing multiple-choice questions can be difficult for screen readers to navigate. In particular it is not possible to associate a unique label with every control in the grid (checkpoint 12.4).
Expanding grids causes such questions to be reformatted so that the checkboxes for each question are displayed in a single column, with a code label shown for each one and with each question one below the other.
Some technologies can correctly navigate grid questions, albeit not as easily as expanded grids, and so, when the requirements of the respondent are known, some authors may prefer to maintain the shape of their grid questions. Note though, that if grids are not expanded, then consideration must be given to the priority 3 check point to provide abbreviations for row and column headers (checkpoint 5.6). Snap has no support for providing such abbreviations, and so cannot pass this check if grids are used but not expanded.
Use <fieldset> around questions (priority 2)
Checkpoint 12.3 (priority 2) asks that information should be formally grouped where natural and appropriate. The documentation goes on to recommend the use of <fieldset> to group logically connected controls in a form.
Although Snap questions naturally form a group around the code options, some authors may feel that <fieldsets> are also required to satisfy this checkpoint. Certainly the use of <fieldset> allows some screen readers to navigate more efficiently and to provide more useful information to respondents about each control.
Note that <fieldsets> does change the appearance of published questionnaires, as most browsers render a <fieldsets> with a prominent border.
Use <fieldsets> around grid members (priority 2)
This option supplements the previous options to expand grids and to use <fieldsets>.
Where grids are expanded it can become difficult to identify where each question in a grid ends and the following one begins. Adding further <fieldsets>s around such grid members aids readability and accessibility, whilst providing more accurate groupings within the markup.
Note that <fieldsets> can only be added to grid members if grids are expanded.
Don't use <font> tags (priority 2)
The tag <font> has widespread use in html to provide character formatting in web pages. Unfortunately <font> is a deprecated language feature and as such is forbidden by checkpoint 11.2.
Note that if <font> is not used then no character formatting will be seen unless a style sheet is also produced. Such formatting includes typeface, text colour and text size. If style sheets are used then <font> will automatically not be used.
External style sheet (priority 2)
Style sheets allow web pages to be produced with formatting separated from content (checkpoint 3.3).
Without style sheets, some aspects of Snap web questionnaires must be rendered in an alternative way using markup which is not formally valid (checkpoint 3.2).
The use of style sheets also allows pages which do not rely upon deprecated markup such as <font> (checkpoint 11.2)
Note that if a style sheet is used for the normal version then one is automatically produced for the plain version, and that when style sheets are produced, the <font> tag is automatically not used.
Explicit tab order (priority 3)
Although Snap web questionnaires always have every link and control arranged in a logical order (checkpoint 9.4), it is still useful to ensure that controls are visited in the correct order by explicitly defining the tab order.
Use <accessKey> (priority 3)
Snap can optionally provide keyboard shortcuts (via accessKey) for the buttons on the plain text version of web questionnaires (checkpoint 9.5). The keys employed are alt+S for reset and alt+S for submit. The keys are highlighted on the tooltips when used.
Browser support for keyboard shortcuts on web links is poor. Some browsers use the shortcut to set focus to the link, but require the respondent to hit enter before following the link. This problem affects web questionnaires when image buttons are used, but questionnaires using regular push buttons respond to keyboard shortcuts well.
It is not practical for shortcuts to be provided for every input control as there are typically too many controls on a web questionnaire.
Although a keyboard shortcut could be provided to step through <fieldset> elements, such shortcuts are not supported by most browsers and cause unsatisfactory behaviour in some screen readers, and are therefore not generated by Snap .
Keyboard shortcuts are not generally easy to use as many screen readers and accessibility tools employ many alt-key combinations as the basis for their user interfaces, and many browsers use them to access menu items. These things mean that whenever keyboard shortcuts are used on web pages, there is a risk of them interfering in unexpected ways with accessibility tools and browsers, making them counter-productive in terms of web accessibility.
Open questions have placeholder text (priority 3)
It is said that some screen reader have trouble identifying edit controls unless they already contain some place-holding text (checkpoint 10.4).
The default is to insert a space. Authors who choose to specify more verbose place-holding text should ensure that all open ended questions are large enough to hold the text. They should also be aware that such text might interfere with Snap's ability to detect questions which have not been answered when holecounts are calculated, and that such place-holding text must either be deleted or overtyped by the respondent, operations which some respondents may have difficulty in performing.
Many browsers and screen readers do successfully find edit controls in web pages, so some authors may not feel the need to use place-holding text.
Web language configuration
There is a program distributed with Snap called ‘web language configuration,’ which can be used to specify the natural language of the survey (checkpoint 4.3). The character set can also be specified where required.
Authors writing surveys in a language other than English will also want to use this program to provide translated text for the various error messages which might be generated by Snap web questionnaires.
3.W3C Guidelines
The W3C web accessibility guidelines, listed with summaries of how Snap supports each checkpoint. The numbers assigned to each checkpoint are the same as those in the Web Content Accessibility Guidelines version 1.0 as published by the W3C.
Checkpoints are grouped according to topic, but are also classified into three priority levels. The W3C suggests that it is important for web authors to satisfy all priority one checkpoints, that they should attempt to satisfy all priority two checkpoints and that ideally they would satisfy all checkpoints.
Symbols are used in these listings to denote:
Details of how Snap can support a checkpoint.
Checkpoints which are satisfied when certain options are selected within Snap.
Checkpoints which are not applicable for Snap web questionnaires.
Methods of supporting a checkpoint which rely upon care from the author as they compose and format their questionnaires.
Guideline 1. Provide equivalent alternatives to auditory and visual content.
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1] (Checkpoint 1.1)
Images are the only non-text elements directly supported by Snap. Snap provides alt text for all embedded images, which can be specified by authors.
Authors can employ other non-text elements in Snap web questionnaires, by inserting custom html fields. In these cases, care should be taken to provide the appropriate descriptive attributes.
1.2 Provide redundant text links for each active region of a server-side image map. [Priority 1] (Checkpoint 1.2)
Snap does not produce server-side image maps.
1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1] (Checkpoint 1.3)
1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1] (Checkpoint 1.4)
Snap doesn't directly support the use of multimedia content.
Authors using multimedia content, by inserting custom html fields or otherwise, should provide auditory descriptions and synchronize equivalent alternatives.
1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3] (Checkpoint 1.5)
Snap does not produce client -side image maps.
Guideline 2. Don't rely on color alone.
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1] (Checkpoint 2.1)
Snap does not employ colour as a means of providing information in web questionnaires.
Authors who assign meaning colours should ensure that the information is otherwise available
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text]. (Checkpoint 2.2)
Snap can optionally ensure that the plain text versions of web questionnaires employ no colours and no images which can help to avoid issues of contrast.
Authors who choose to use colour on their plain text version should ensure a sufficient contrast in the colour scheme they design.
Guideline 3. Use markup and style sheets and do so properly.
3.1 When an appropriate markup language exists, use markup rather than images to convey information. [Priority 2] (Checkpoint 3.1)
Authors using non-text content, by inserting custom html fields or otherwise, should use suitable markup where available.
3.2 Create documents that validate to published formal grammars. [Priority 2] (Checkpoint 3.2)
Versions of Snap web questionnaires which use external style sheets are valid html 4 transitional web pages. ("-//W3C//DTD HTML 4.0 Transitional//EN")
Where Snap web questionnaires fail DTD validation, it is typically in the use of attributes and features from earlier versions of HTML which are no longer formally valid, but which cannot be reproduced in any practical alternative way. In particular, when style sheets are not employed, some of the alternative layout elements are formally regarded as deprecated. (In fact some cosmetic attributes, such as the attribute ‘border’ as used within the tag <frameset>, are considered deprecated even though they cannot be reproduced with style sheet settings.)
In the absence of style sheets, the markup employed is wholly supported by all major browsers, and their use typically has minimal impact on accessibility tools.
3.3 Use style sheets to control layout and presentation. [Priority 2] (Checkpoint 3.3)
Snap can optionally produce an external style sheet for the plain text version of a web survey.
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. [Priority 2] (Checkpoint 3.4)
Snap uses relative units where ever possible and when style sheets are employed, relative units are always used.
3.5 Use header elements to convey document structure and use them according to specification. [Priority 2] (Checkpoint 3.5 )
When style sheets are employed, any ‘note’ type variables from Snap are rendered using suitable header tags, chosen based on the font size used in the questionnaire style.
3.6 Mark up lists and list items properly. [Priority 2] (Checkpoint 3.6)
Snap does not employ lists or list items.
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. [Priority 2] (Checkpoint 3.7)
Snap does not directly support quotations, but quotation tags can be inserted as custom html fields
Authors should take care if they choose to insert markup for quotations. Unfortunately the most popular of the current browsers does not support the <q> tag, making it impossible to obtain consistent results.
Guideline 4. Clarify natural language usage
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [Priority 1] (Checkpoint 4.1 )
Authors can mark any change of language by inserting custom html objects into Snap surveys. Each text field written in a language other than the default one should use a custom html object at both ends. The start of the field should have an object containing <span lang=”xx”>, where ‘xx’ is any valid language code (such as ‘en’ for English or ‘fr’ for French). The end of the field should have an object containing </span>
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3] (Checkpoint 4.2)
Authors can insert custom html objects as required.
An object is required on each side of the abbreviation or acronym. The one before the text should contain “<ACRONYM title="xxx">” where ‘xxx’ is the required expansion., and the one after it should contain “</ACRONYM>”
4.3 Identify the primary natural language of a document. [Priority 3] (Checkpoint 4.3)
Snap identifies the primary language within the <html> tags of its web questionnaires. The default is ‘en’(English).
There is a program distributed with Snap called ‘web language configuration’ which can be used to specify the natural language of the survey. The character set can also be specified where required. Authors writing surveys in a language other than English will also want to use this program to provide translated text for the various error messages which might be generated by Snap web questionnaires.
Guideline 5. Create tables that transform gracefully.
5.1 For data tables, identify row and column headers. [Priority 1] (Checkpoint 5.1)
Grid questions in web questionnaires from Snap have their code labels and grid labels encased in <TH> elements and the ‘scope’ attribute is defined for these elements a s appropriate.
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1] (Checkpoint 5.2)
No such tables currently exist in Snap web questionnaires.
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2] (Checkpoint 5.3 )
Snap web questionnaires remain readable when layout tables are linearized.
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2] (Checkpoint 5.4)
Snap does not use structural elements to achieve visual formatting. Such formatting is achieved either through a style sheet or, where style sheets are not employed, by the use of the <font> tag in combination with attributes such as ‘align’ and ‘background’.
When structural markup is use, it is consistent with the meaning of the text.
5.5 Provide summaries for tables. [Priority 3] (Checkpoint 5.5)
All tables in Snap web questionnaires contain summaries.
5.6 Provide abbreviations for header labels. [Priority 3] (Checkpoint 5.6 )
This requirement is only relevant where multi-choice grids are used. Meaningful header abbreviations cannot be calculated by Snap as they depend upon the meaning and context of the question.
To comply, change girds into successions of standard multi-choice questions or produce a text version with the 'expand grids' option selected.
Guideline 6. Ensure that pages featuring new technologies transform gracefully.
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1] (Checkpoint 6.1)
When a style sheet is produced, the web questionnaires are still fully readable when the style sheet is inaccessible.
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1] (Checkpoint 6.2)
Multi-page surveys only employ dynamic behaviour when the respondent navigates to the next or previous page. All data is fully updated at this point.
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1] (Checkpoint 6.3)
When a plain text version of a Snap survey is produced together with a dynamic normal version, respondents without scripting are directed towards the plain text version.
6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2] (Checkpoint 6.4)
Unmodified Snap web questionnaires do not utilise device-dependent event handlers.
6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2] (Checkpoint 6.5)
Snap can optionally produce a plain text accessible version of each web survey. A link to the text version appears on the first page of the normal version and respondents without scripting are direct towards it as well.
Guideline 7. Ensure user control of time-sensitive content changes.
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1] (Checkpoint 7.1)
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2] (Checkpoint 7.2)
7.3 Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2] (Checkpoint 7.3)
Snap does not directly produce flickering or blinking effects, or any moving content.
Authors must be aware to avoid inserting animated GIF files, or other multimedia content, which cause flickering, blinking or movement effects.
7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. [Priority 2] (Checkpoint 7.4)
Snap web questionnaires do not auto - refresh
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. [Priority 2] (Checkpoint 7.5)
Snap web questionnaires do not use automatic redirection.
Guideline 8. Ensure direct accessibility of embedded user interfaces.
8.1 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.] (Checkpoint 8.1 )
The plain text version of Snap web questionnaires employ no programmatic elements.
The only programmatic elements of Snap web questionnaires operates when dynamic versions of the survey need to change page, following respondent input, and as such does not provide content which assistive technologies require to represent.
Guideline 9. Design for device-independence.
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. [Priority 1] (Checkpoint 9.1)
Snap does not produce image maps.
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2] (Checkpoint 9.2)
Snap does not employ any element with an interface besides the standard html form controls.
Authors using non-text content, by inserting custom html fields or otherwise, should ensure device independent interaction where applicable.
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2] (Checkpoint 9.3)
Unmodified Snap web questionnaires do not utilise device-dependent event handlers.
9.4 Create a logical tab order through links, form controls, and objects. [Priority 3] (Checkpoint 9.4)
Snap can optionally provide an explicit tab order for the plain text version of web questionnaires. However, even without an explicit tab order, every control and link always appear in the web page in a logical order.
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. [Priority 3] (Checkpoint 9.5)
Snap can optionally provide keyboard shortcuts (via accessKey) for the buttons on the plain text version of web questionnaires. The keys employed are alt+R for reset and alt+S for submit. The keys are highlighted on the tooltips when used.
Browser support for keyboard shortcuts on web links is poor. Some browsers use the shortcut to set focus to the link, but require the respondent to hit enter before following the link. This problem affects web questionnaires when image buttons are used, but questionnaires using regular push buttons respond to keyboard shortcuts well.
Keyboard shortcuts are not generally easy to use as many screen readers and accessibility tools employ many alt-key combinations as the basis for their user interfaces, and many browsers use them to access menu items. These things mean that whenever keyboard shortcuts are used on web pages, there is a risk of them interfering in unexpected ways with accessibility tools and browsers, making them counter-productive in terms of web accessibility.
Guideline 10. Use interim solutions.
10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2] (Checkpoint 10.1)
The current window is only changed on JavaScript web questionnaires from Snap when a respondent uses the next or previous page buttons and the non JavaScript versions of Snap web questionnaires always open links in the same window.
User inserted links in the JavaScript version of a questionnaire do open in another window. This is because once the survey has been left, the back button cannot be relied upon to restore the answers and location within the survey correctly, when the respondent wishes to complete the survey.
10.2 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] (Checkpoint 10.2)
When producing the plain text version of web questionnaires, Snap can optionally ensure that all labels are properly positioned.
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. [Priority 3] (Checkpoint 10.3)
This checkpoint is an issue for multiple choice questions where the codes are laid out in multiple columns and for surveys where multiple columns are specified on the page.
The plain text version of Snap web questionnaires always constrain questions to display in single columns.
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] (Checkpoint 10.4)
Snap can optionally provide place-holding characters in edit boxes and text areas of the plain text version of web questionnaires. The default is to insert a space.
Authors who choose to specify more verbose place-holding text should ensure that all open ended questions are large enough to hold the text. They should also be aware that such text might interfere with Snap's ability to detect questions which have not been answered when holecounts are calculated, and that such place-holding text must either deleted or overtyped by the respondent, operations which some respondents may have difficulty in performing.
Many browsers and screen readers do successfully find edit controls in web pages, so some authors may not feel the need to use place-holding text.
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3] (Checkpoint 10.5)
Authors who choose to insert html web link objects should ensure that suitable dividing characters are inserted as required.
Guideline 11. Use W3C technologies and guidelines.
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2] (Checkpoint 11.1)
Snap uses HTML 4 and optionally uses CSS, which are both W3C technologies.
11.2 Avoid deprecated features of W3C technologies. [Priority 2] (Checkpoint 11.2)
Versions of Snap web questionnaires which use a style sheet are free of all deprecated features.
Non style sheet versions must still use the <font> and sometimes <u> tags, as there is no other way to format text in the absence of style sheets.
11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) [Priority 3] (Checkpoint 11.3)
Snap does not support multiple versions of surveys, for language or content
Authors may choose to produce multiple surveys with Snap in order to present respondents with a choice, as appropriate.
11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. [Priority 1] (Checkpoint 11.4)
Snap can optionally produce a plain text accessible version of any web questionnaire. The two versions are produced together, along with any other files that are needed, and authors should ensure that if a survey is updated then the latest version of every file is uploaded to their web site as appropriate.
Guideline 12. Provide context and orientation information.
12.1 Title each frame to facilitate frame identification and navigation. [Priority 1] (Checkpoint 12.1)
Multi page dynamic web questionnaire use a hidden frame to contain the question data and a visible frame to display the pages of the questionnaire. Titles are provided for these frames.
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2] (Checkpoint 12.2)
The titles are considered sufficient for the Snap dynamic web questionnaires.
12.3 Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2] (Checkpoint 12.3 )
Snap web questionnaires are naturally divided in questions.
When a large number of controls appear on a page, some accessibility tools have difficulty associating related controls together. When mutli–choice questions are used, accessibility can be enhanced by placing each one on a page by itself, or by using drop down controls instead of radio buttons.
The plain text version of web questionnaires can optionally place <fieldsets> around questions and around the controls representing a single part of a grid question. This helps some screen readers to associate controls together as appropriate and is recommended by the W3C guidelines.
12.4 Associate labels explicitly with their controls. [Priority 2] (Checkpoint 12.4)
Snap explicitly associates labels with their controls wherever possible.
Multi-choice grid questions do not have a unique label for every control, so this checkpoint cannot be fully satisfied when grid questions are used. Authors should also ensure that code labels are showing for all questions as appropriate.
The plain text version of web questionnaires can optionally expand grids which ensures that there is a label for every control.
Guideline 13. Provide clear navigation mechanisms.
13.1 Clearly identify the target of each link. [Priority 2] (Checkpoint 13.1)
When authors insert web links, they should ensure that suitable link text is used.
13.2 Provide metadata to add semantic information to pages and sites. [Priority 2] (Checkpoint 13.2)
Snap web surveys include several piece of metadata including a <title> element and a <meta name="generator"> element.
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents). [Priority 2] (Checkpoint 13.3)
13.4 Use navigation mechanisms in a consistent manner. [Priority 2] (Checkpoint 13.4)
13.5 Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3] (Checkpoint 13.5)
Not applicable for Snap surveys. Authors who need to provide site navigation or other site information must either modify the html files after publishing or can host the web questionnaire from a section of their web site which also hosts the required information, for example by hosting the questionnaire in a frame on another page or by running it as a popup questionnaire.
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3] (Checkpoint 13.6)
Not applicable for Snap surveys.
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences. [Priority 3] (Checkpoint 13.7)
Not applicable for Snap surveys.
13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3] (Checkpoint 13.8)
Authors should be aware of this checkpoint as they compose the text of their questionnaires.
13.9 Provide information about document collections (i.e., documents comprising multiple pages.). [Priority 3] (Checkpoint 13.9)
Not applicable for Snap surveys.
13.10 Provide a means to skip over multi-line ASCII art. [Priority 3] (Checkpoint 13.10)
Not applicable for Snap surveys.
Guideline 14. Ensure that documents are clear and simple.
14.1 Use the clearest and simplest language appropriate for a site's content. [Priority 1] (Checkpoint 14.1)
Authors should be aware of this checkpoint as they compose the text of their questionnaires.
14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. [Priority 3] (Checkpoint 14.2)
Where appropriate extra elements can be added by inserting images or custom html objects.
14.3 Create a style of presentation that is consistent across pages. [Priority 3] (Checkpoint 14.3)
Authors should be aware of this checkpoint as they compose the text of their questionnaires.
4. Cross reference by priority
A summary of the W3C checkpoints, sorted by priority, with information about which versions of Snaps web questionnaires support each checkpoint.
Symbols are used in these listings to denote:
- Checkpoints which are fully satisfied by Snap web questionnaires
- Checkpoints which are satisfied by not being applicable.
- Checkpoints which are dependant upon the content supplied by the author.
- Checkpoints which are supported if certain options are used in Snap
- Checkpoints which are not fully supported by Snap
Priority 1
| Check - point | Summary | Supported by Snap normal version | Supported by Snap plain text version |
|---|---|---|---|
| 1.1 | Use Alt text | Fully Supported |
Fully Supported |
| 1.2 | Redundant links for image maps | Not applicable |
Not applicable |
| 1.3 | Auditory description for multimedia | Not applicable |
Not applicable |
| 1.4 | Synchronize multimedia alternatives | Not applicable |
Not applicable |
| 2.1 | Don't rely on colour | Author's responsibility |
Option available (remove colour) |
| 4.1 | Identify changes in language | Author's responsibility (supported by ‘insert HTML’) |
Author's responsibility (supported by ‘insert HTML’) |
| 5.1 | Markup headers in data tables | Fully Supported |
Fully Supported |
| 5.2 | Markup complex data tables | Not applicable |
Not applicable |
| 6.1 | Transform without style sheets | Fully Supported |
Fully Supported |
| 6.2 | Synchronize dynamic content | Fully Supported |
Fully Supported |
| 6.3 | Usability when scripting is removed | Supported in static questionnaires or if plain version produced |
Not applicable |
| 7.1 | Avoid flickering | Author's responsibility when using animated images |
Author's responsibility when using animated images |
| 9.1 | Favour client-side image maps | Not applicable |
Not applicable |
| 11.4 | Provide fully accessible alternative | Supported if plain version produced |
Not applicable |
| 12.1 | Title each frame | Fully Supported |
Not applicable |
| 14.1 | Use clear language | Author's responsibility |
Author's responsibility |
| Overall Priority 1 | Supported in static questionnaires or if plain version produced |
Supported (dependant on some author supplied content) |
Priority 2
| Check - point | Summary | Supported by Snap normal version | Supported by Snap plain text version |
|---|---|---|---|
| 2.2 | Use contrasting colours in images | Author's responsibility |
Option available (remove images) |
| 3.1 | Use custom markup where appropriate | Author's responsibility (supported by ‘insert HTML’) |
Author's responsibility (supported by ‘insert HTML’) |
| 3.2 | Ensure validation to formal DTD | Supported if external style sheet produced. |
Supported if external style sheet produced. |
| 3.3 | Use style sheets | Option available (external style sheet) |
Option available (external style sheet) |
| 3.4 | Use relative measurements | Fully supported |
Fully supported |
| 3.5 | Used header elements correctly | Header elements only used when style sheet produced. |
Header elements only used when style sheet produced. |
| 3.6 | Markup lists | Not applicable |
Not applicable |
| 3.7 | Mark up quotations | Author's responsibility (supported by ‘insert HTML’) |
Author's responsibility (supported by ‘insert HTML’) |
| 5.3 | Maintain readability when tables are linearized | Fully Supported |
Fully Supported |
| 5.4 | Do not rely on structural mark up for visual formatting | Fully Supported |
Fully Supported |
| 6.4 | No device-dependent event handlers | Fully Supported |
Fully Supported |
| 6.5 | Provide alternative to dynamic content | Not applicable / plain version available |
Not applicable |
| 7.2 | Avoid blinking | Author's responsibility when using animated images |
Author's responsibility when using animated images |
| 7.3 | Avoid movement | Author's responsibility when using animated images |
Author's responsibility when using animated images |
| 7.4 | No auto-refresh | Fully Supported |
Fully Supported |
| 7.5 | No auto re-direct | Not applicable |
Not applicable |
| 8.1 | Make programmatic elements accessible | Fully Supported |
Not applicable |
| 9.2 | Use device-independent components | Not applicable |
Not applicable |
| 9.3 | Avoid device-dependent event handlers | Fully Supported |
Fully Supported |
| 10.1 | No popup windows | Supported except where links are inserted into dynamic surveys |
Fully Supported |
| 10.2 | Position labels properly | Author's responsibility |
Option available (position labels) |
| 11.1 | Use W3C technologies | Fully Supported |
Fully Supported |
| 11.2 | Avoid deprecated features | Supported if external style sheet produced. |
Supported if external style sheet produced or if <font> not used (Option available) |
| 12.2 | Describe frames when appropriate | Not applicable |
Not applicable |
| 12.3 | Divide large blocks of information | Arguably not fully supported when checkbox or radio button questions appear on a page with other questions. |
Option available (use <fieldset>s) |
| 12.4 | Associate labels explicitly | Supported where multi-choice grids are not used |
Fully Supported if grids are expanded (option available) |
| 13.1 | identify the target of each link | Author's responsibility for inserted links. Otherwise supported |
Author's responsibility for inserted links. Otherwise supported |
| 13.2 | Provide metadata as appropriate | Fully Supported |
Fully Supported |
| 13.3 | Site layout information | Not applicable : Author's responsibility when hosting on a web site |
Not applicable : Author's responsibility when hosting on a web site |
| 13.4 | Consistent navigation mechanisms | Not applicable : Author's responsibility when hosting on a web site |
Not applicable : Author's responsibility when hosting on a web site |
| Overall Priority 2 | Supported dependant on author supplied content. Use of style sheets and plain text version recommended to ensure compliance. |
Fully supported if all strict options are used. (dependant on some author supplied content) |
Priority 3
| Check - point | Summary | Supported by Snap normal version | Supported by Snap plain text version |
|---|---|---|---|
| 1.5 | Redundant links for image maps | Not applicable |
Not applicable |
| 2.2 | Use contrasting colours in text | Author's responsibility |
Option available (remove colour) |
| 4.2 | Specify abbreviations / acronyms | Author's responsibility |
Author's responsibility |
| 4.3 | Identify primary language. | Fully supported (by associated configuration program) |
Fully supported (by associated configuration program) |
| 5.5 | Summaries in tables | Fully supported |
Fully supported |
| 5.6 | Abbreviations for header labels | Supported only where multi-choice grids are not used |
Not applicable if grids are expanded (option available) |
| 9.4 | Create a logical tab order | supported |
Supported and option available (explicit tab order) |
| 9.5 | keyboard shortcuts for important links | Not supported |
Supported for buttons (impractical for every control) |
| 10.3 | Linear alternatives for parallel text | Not supported if multiple columns are used |
Fully supported (columns automatically removed) |
| 10.4 | Provide placeholder text for edit controls | Not supported |
Options available (placeholder text) |
| 10.5 | Layout around adjacent links | Author's responsibility |
Author's responsibility |
| 11.3 | Support user preferences | Not applicable: Author's responsibility when hosting on a web site |
Not applicable: Author's responsibility when hosting on a web site |
| 13.5 | navigation bars | Not applicable: Author's responsibility when hosting on a web site |
Not applicable: Author's responsibility when hosting on a web site |
| 13.6 | Group related links | Not applicable |
Not applicable |
| 13.7 | Search functions | Not applicable |
Not applicable |
| 13.8 | Paragraph structure | Author's responsibility |
Author's responsibility |
| 13.9 | document collections | Not applicable |
Not applicable |
| 13.10 | ASCII art. | Not applicable |
Not applicable |
| 14.2 | Use sound or graphics where useful | Author's responsibility |
Author's responsibility |
| 14.3 | Consistent presentation | Author's responsibility |
Author's responsibility |
| Overall Priority 3 | Not fully supported - production of plain text version recommended |
Fully supported if all strict options are used. (dependant on some author supplied content) |
Return to Accessibility Overview