Building an Accessible site in Terminalfour
This outlines the steps to take to assist in the creation of an accessible site in Terminalfour.
Check the initial code supplied
The first step is ensuring that your site's initial code (HTML, CSS, etc.) meets the relevant accessibility standard. For this, we are basing our advice on the WCAG 2.1 standard.
The organization WebAIM offers a free online accessibility evaluation tool. This tool can be used to check the initial code for compliance. The tool will highlight issues on the page in the following categories:
- Errors
- Alerts
- Features
- Structural Elements
- HTML5 and ARIA
- Contrast Errors
For each issue, it will give an explanation, documentation and links to the relevant standards and guidelines.
Once you are happy with the initial code, then the next step is to implement into Terminalfour.
Implementing the code in Terminalfour
When the code is being implemented in Terminalfour, it is important that the accessibility standards are maintained. The Administrator/Power User creating the Page Layouts, Navigation Objects, Content Types and Media Types should ensure that they are built in such a way that the accessibility standards can be maintained. During, and at the end of the implementation, it is recommended that the site is tested again using the accessibility evaluation tool.
A good way to test assets is to create an area of your site where you publish content using a combination of site assets, i.e., Page Layouts, Navigation Objects, Content Types and Media Types. This allows for tests to be run in a controlled way and for any issues to be resolved before finalizing the implementation. Subsequent changes to site assets can also be tested. Please reference the section below.
Creating and editing content
Before creating and editing content on the site, we advise that the content editing environment is set up to match the needs of your users and the accessibility standards you wish to maintain. Further advice and guidelines are provided below.
HTML Elements
For content that contains HTML elements, an HTML Editor can be used. Different HTML editors can be assigned to different users. We advise that the default editor is configured in such a way that the minimum buttons/toolbars are provided. Common items that are removed from the editor are view source, underline and justify text. For more advanced content editors another editor can be provided and assigned to those users.
Workflow
Consider the use of a Workflow or approval step to allow for checking of content accessibility. Once the users have been trained on accessibility, a recommended approach is to include a step for checking content for accessibility compliance.
Governance, guidance and training
All changes to assets and content are audited and version controlled in Terminalfour. We advise that consideration is given to accessibility standards when users are set up on the system. They should be given sufficient access, tools, training and support to ensure standards are understood and maintained.
Accessibility reporting
The Terminalfour Accessibility Report can be used to highlight issues that need to be addressed for compliance. In Version 8 of Terminalfour, the Accessibility Report is redirected to the Version 7 interface for the configuration. We are currently reviewing the accessibility features in the product to improve them and make them easier to configure and use.
Terminalfour Best Practice Guidelines
The guidelines have been outlined in two parts; Implementation and Content.
Implementation
In Content Types and Page Layouts:
- The language of the page should be specified in the
html tag - T4 Tags should be utilized to ensure pages have a descriptive and informative page title
- Provide a link to skip navigation and other page elements that are repeated across pages
- Images should have alt and longdesc attributes
- Breadcrumb navigation should be used to indicate the location of the page in a sequence of pages
Content elements
When designing Content Types, consideration should be given to the most suitable element to use to limit/enforce creation of accessible content.
Content
It is advised that guidelines for writing accessible content are produced for content editors. Some of the main points to cover are:
- The advised structure of heading tags on the page. Do the content editors set them in the content or are some set in Page Layouts and Content Layouts?
- When creating links, the purpose of the link should be clear from the link text or from the surrounding text content. Links pointing to the same location should have the same description. Links pointing to different locations should not have the same description.
Images
The Media Library is used to manage media on the site. It is recommended that an accessible media Content Layout is implemented for images that are added via the HTML WYSIWYG editor. It is advised that the format allows for alt text to be taken from the "Description" of the media and for an optional "longdesc" and "title" to be added. Please see the "How to Create a Media Content Layout to Facilitate Accessible Images" article.
Audio / Video
Again, the Media Library can be used to set up specific media types for different types of audio and video content. Also, specific Content Types can be created for audio and video content. It is advised that a review of the types of audio/video content and the use cases are undertaken before setting them up to ensure that the best methods are chosen for the particular requirements of the site and the users.
Tables
Tables should only be used for tabular data. The TinyMCE editor can be used to add tables:
To add table header <th> tags:
- Select the top row of cells
- Open the table properties menu from the menu bar
- Select Cell > Cell Properties > Cell type > Header Cell
To add a table caption:
- From the table menu
- Click Table properties to open the Table properties dialog box
- Click the General tab
- Enable captions
- Then when you are back in the editor, you can type in the caption
Forms
Forms added with the Form Builder can be configured to be WCAG compliant. Please consult individual WCAG guidelines below.
WCAG 2.0 Checklist
The following table outlines the WCAG 2.0 guidelines and the level (A, AA or AAA). It also explains how Terminalfour supports the guideline and provides a link to further information on best practice configuration. This information has been based on WebAIM's WCAG 2.0 Checklist and their recommendations have also been included.
| # | Guideline | Description / Success Criteria | Level | How Terminalfour supports this Guideline | Terminalfour Best Practice Configuration | WebAIM's Recommendations |
|---|---|---|---|---|---|---|
| 1 | 1 | Perceivable: Web content is made available to the senses - sight, hearing, and/or touch | N/A | N/A | See individual Success Criteria | See individual Success Criteria |
| 2 | 1.1 | Text Alternatives: Provide text alternatives for any non-text content | N/A | See individual Success Criteria | See individual Success Criteria | |
| 3 | 1.1.1 Non-text Content | A | All images, form image buttons and image map hot spots can be configured with alternative text. | Content: Images | All images, form image buttons, and image map hot spots have appropriate, equivalent alternative text. | |
| 4 | 1.1.1 Non-text Content | A | All images can be locked down with mandatory ALT or LONGDESC attributes both in Content Types and Page Layouts. | Implementation advice | Images that do not convey content are decorative or contain content that is already conveyed in text are given null alt text (alt="") or implemented as CSS backgrounds. All linked images have descriptive alternative text. | |
| 5 | 1.1.1 Non-text Content | A | All images can be locked down with mandatory LONGDESC attributes both in Content Types and Page Layouts. | Content: Images | Equivalent alternatives to complex images are provided in context or on a separate (linked and/or referenced via longdesc) page. | |
| 6 | 1.1.1 Non-text Content | A | Form image buttons are not used in Form Builder. Other forms added can be configured to be WCAG compliant. | Content: Forms | Form buttons have a descriptive value. | |
| 7 | 1.1.1 Non-text Content | A | Form inputs are accompanied by text labels in Form Builder. Other forms added can be configured to be WCAG compliant. | Content: Forms | Form inputs have associated text labels. | |
| 8 | 1.1.1 Non-text Content | A | Content types can be configured to be WCAG compliant and locked down accordingly. | Implementation advice | Embedded multimedia is identified via accessible text. | |
| 9 | 1.1.1 Non-text Content | A | Frames are not used in Form Builder. Frames added can be configured to be WCAG compliant. | Implementation advice | Frames are appropriately titled. | |
| 10 | 1.2 | Time-based Media: Provide alternatives for time-based media. NOTE: If the audio or video is designated as an alternative to web content (e.g., an audio or sign language version of a web page, for example), then the web content itself serves as the alternative. | N/A | N/A | See individual Success Criteria | See individual Success Criteria |
| 11 | 1.2.1 Prerecorded Audio-only and Video-only | A | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | A descriptive text transcript (including all relevant visual and auditory clues and indicators) is provided for non-live, web-based audio (audio podcasts, MP3 files, etc.). | |
| 12 | 1.2.1 Prerecorded Audio-only and Video-only | A | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | A text or audio description is provided for non-live, web-based video-only (e.g., a video that has no audio track). | |
| 13 | 1.2.2 Captions (Prerecorded) | A | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | Synchronized captions are provided for non-live, web-based video (YouTube videos, etc.) | |
| 14 | 1.2.3 Audio Description or Media Alternative (Prerecorded) | A | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | A descriptive text transcript OR audio description audio track is provided for non-live, web-based video | |
| 15 | 1.2.4 Captions (Live) | AA | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | Synchronized captions are provided for all live multimedia that contains audio (audio-only broadcasts, web casts, video conferences, Flash animations, etc.) | |
| 16 | 1.2.5 Audio Description (Prerecorded) | AA | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | Audio descriptions are provided for all video content | |
| 17 | 1.2.5 Audio Description (Prerecorded) | AA | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | NOTE: Only required if the video conveys content visually that is not available in the default audio track. | |
| 18 | 1.2.6 Sign Language (Prerecorded) | AAA | N/A | Content: Audio / Video | A sign language video is provided for all media content that contains audio. | |
| 19 | 1.2.7 Extended Audio Description (Prerecorded) | AAA | N/A | Content: Audio / Video | When an audio description track cannot be added to video due to audio timing (e.g., no pauses in the audio), an alternative version of the video with pauses that allow audio descriptions is provided. | |
| 20 | 1.2.8 Media Alternative (Prerecorded) | AAA | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | A descriptive text transcript is provided for all pre-recorded media that has a video track. | |
| 21 | 1.2.9 Audio-only (Live) | AAA | Outside the scope of Terminalfour but all types of accessible video embed code is supported. If storing files locally or creating a Content Type that supports the embed code additional accessibility related fields can be locked down and made mandatory. | Content: Audio / Video | A descriptive text transcript (e.g., the script of the live audio) is provided for all live content that has audio. | |
| 22 | 1.3 | Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure | NA | See individual Success Criteria | See individual Success Criteria | |
| 23 | 1.3.1 Info and Relationships | A | All markup can be locked down at a Page Layout or Content Type level. Within the TinyMCE editor, we recommend not using or removing the option for H1 tags and have these set in the Page Layout. The correct use of heading levels should be explained to content editors so that heading levels are not used for formatting reasons. | Implementation advice & Content: General | Semantic markup is used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately. | |
| 24 | 1.3.1 Info and Relationships | A | Accessible tables can be created within the TinyMCE editor. One area that needs to be improved in Terminalfour is that the TABLE creator doesn't force a user to enter the fields for an accessible table. The checker currently won't return an issue with accessible tables. |
Content: Tables | Tables are used for tabular data. Where necessary, data cells are associated with their headers. Data table captions and summaries are used where appropriate. | |
| 25 | 1.3.1 Info and Relationships | A | Text labels are associated with form input elements in Form Builder. Other forms added can be configured to be WCAG compliant. | Content: Forms | Text labels are associated with form input elements. Related form elements are grouped with fieldset/legend. | |
| 26 | 1.3.2 Meaningful Sequence | A | Relates to content authoring but nothing in Terminalfour will restrict you implementing best practice. | Implementation advice | The reading and navigation order (determined by code order) is logical and intuitive. | |
| 27 | 1.3.3 Sensory Characteristics | A | Relates to content authoring / content type creation but nothing in Terminalfour will restrict you implementing best practice. | Content: General | Instructions do not rely upon shape, size, or visual location (e.g., "Click the square icon to continue" or "Instructions are in the right-hand column"). | |
| 28 | 1.3.3 Sensory Characteristics | A | Relates to content authoring but nothing in Terminalfour will restrict you implementing best practice. | Content: General | Instructions do not rely upon sound (e.g., "A beeping sound indicates you may continue."). | |
| 29 | 1.4 | Distinguishable: Make it easier for users to see and hear content including separating foreground from background | NA | See individual Success Criteria | See individual Success Criteria | |
| 30 | 1.4.1 Use of Color | A | Relates to web design but nothing in Terminalfour will restrict you implementing best practice. Once a high-quality web design is created it can be completely locked down to stop a user altering it. | Implementation advice & Content: General | Color is not used as the sole method of conveying content or distinguishing visual elements. | |
| 31 | 1.4.1 Use of Color | A | Relates to web design but nothing in Terminalfour will restrict you implementing best practice. Once a high-quality web design is created it can be completely locked down to stop a user altering it. | Implementation advice & Content: General | Color alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus. | |
| 32 | 1.4.2 Audio Control | A | Content: Audio / Video | A mechanism is provided to stop, pause, mute, or adjust volume for audio that automatically plays on a page for more than 3 seconds. | ||
| 33 | 1.4.3 Contrast (Minimum) | AA | Relates to web design but nothing in Terminalfour will restrict you implementing best practice. Once a high-quality web design is created it can be completely locked down to stop a user altering it. | Implementation advice & Content: General | Text and images of text have a contrast ratio of at least 4.5:1. | |
| 34 | 1.4.3 Contrast (Minimum) | AA | Relates to web design but nothing in Terminalfour will restrict you implementing best practice. Once a high-quality web design is created it can be completely locked down to stop a user altering it. | Implementation advice & Content: General | Large text - at least 18 point (typically 24px) or 14 point (typically 18.66px) bold has a contrast ratio of at least 3:1. | |
| 35 | 1.4.4 Resize text | AA | Relates to web design but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Implementation advice & Content: General | The page is readable and functional when the text size is doubled. | |
| 36 | 1.4.5 Images of Text | AA | Web design/content best practice. | Content: General | If the same visual presentation can be made using text alone, an image is not used to present that text. | |
| 37 | 1.4.6 Contrast (Enhanced) | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Content: General | Text and images of text have a contrast ratio of at least 7:1. | |
| 38 | 1.4.6 Contrast (Enhanced) | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Implementation advice & Content: General | Large text - at least 18 point (typically 24px) or 14 point (typically 18.66px) bold has a contrast ratio of at least 4.5:1. | |
| 39 | 1.4.7 Low or No Background Audio | AAA | Web design / content best practice. | Content: Audio / Video | Audio of speech has no or very low background noise, so the speech is easily distinguished. | |
| 40 | 1.4.8 Visual Presentation | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Content: General | Blocks of text over one sentence in length: | |
| 41 | 1.4.8 Visual Presentation | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Content: General | Are no more than 80 characters wide. | |
| 42 | 1.4.8 Visual Presentation | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Content: General | Are NOT fully justified (aligned to both the left and the right margins). | |
| 43 | 1.4.8 Visual Presentation | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Content: General | Have adequate line spacing (at least 1/2 the height of the text) and paragraph spacing (1.5 times line spacing). | |
| 44 | 1.4.8 Visual Presentation | AAA | Relates to web design, but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created, it can be completely locked down to stop a user from altering it. | Content: General | Have a specified foreground and background color. These can be applied to specific elements or to the page as a whole using CSS (and thus inherited by all other elements). | |
| 45 | 1.4.8 Visual Presentation | AAA | Relates to web design but nothing in Terminalfour will restrict you from implementing best practice. Once a high-quality web design is created it can be completely locked down to stop a user from altering it. | Content: General | Do NOT require horizontal scrolling when the text size is doubled. | |
| 46 | 1.4.9 Images of Text (No Exception) | AAA | Web design / content best practice. | Content: General | Text is used within an image only for decoration (image does not convey content) OR when the information cannot be presented with text alone. | |
| 47 | 2 | Operable: Interface forms, controls, and navigation are operable | NA | See individual Success Criteria | See individual Success Criteria | |
| 48 | 2.1 | Keyboard Accessible: Make all functionality available from a keyboard | NA | See individual Success Criteria | See individual Success Criteria | |
| 49 | 2.1.1 Keyboard | A | Once a best practice web design has been created it can be completely locked down. New navigation created can also have associated access keys. | Implementation advice | All page functionality is available using the keyboard unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing). | |
| 50 | 2.1.1 Keyboard | A | Web design / content best practice. | Implementation advice | Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts. | |
| 51 | 2.1.2 No Keyboard Trap | A | Web design / content best practice. | Implementation advice | Keyboard focus is never locked or trapped at one particular page element. The user can navigate to and from all navigable page elements using only a keyboard. | |
| 52 | 2.1.3 Keyboard (No Exception) | AAA | Web design / content best practice. | Implementation advice | All page functionality is available using the keyboard. | |
| 53 | 2.2 | Enough Time: Provide users enough time to read and use content | NA | See individual Success Criteria | See individual Success Criteria | |
| 54 | 2.2.1 Timing Adjustable | A | Web design/content best practice. | Implementation advice | If a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit. This is not a requirement for real-time events (e.g., an auction), where the time limit is absolutely required, or if the time limit is longer than 20 hours. | |
| 55 | 2.2.2 Pause, Stop, Hide | A | Web design/content best practice. | Implementation advice | Automatically moving, blinking, or scrolling content that lasts longer than 5 seconds can be paused, stopped, or hidden by the user. Moving, blinking, or scrolling can be used to draw attention to or highlight content as long as it lasts less than 5 seconds. | |
| 56 | 2.2.2 Pause, Stop, Hide | A | Web design / content best practice. | Implementation advice | Automatically updating content (e.g., automatically redirecting or refreshing a page, a news ticker, AJAX updated field, a notification alert, etc.) can be paused, stopped, or hidden by the user or the user can manually control the timing of the updates. | |
| 57 | 2.2.3 No Timing | AAA | Web design/content best practice. | Implementation advice | The content and functionality has no time limits or constraints. | |
| 58 | 2.2.4 Interruptions | AAA | Web design/content best practice. | Implementation advice | Interruptions (alerts, page updates, etc.) can be postponed or suppressed by the user. | |
| 59 | 2.2.5 Re-authenticating | AAA | Web design/content best practice. | Implementation advice | If an authentication session expires, the user can re-authenticate and continue the activity without losing any data from the current page. | |
| 60 | 2.3 | Seizures: Do not design content in a way that is known to cause seizures | NA | See individual Success Criteria | See individual Success Criteria | |
| 61 | 2.3.1 Three Flashes or Below Threshold | A | Web design/content best practice. | Implementation advice | No page content flashes more than 3 times per second unless that flashing content is sufficiently small and the flashes are of low contrast and do not contain too much red. (See general flash and red flash thresholds) | |
| 62 | 2.3.2 Three Flashes | AAA | Web design/content best practice. | Implementation advice | No page content flashes more than 3 times per second. | |
| 63 | 2.4 | Navigable: Provide ways to help users navigate, find content, and determine where they are | NA | See individual Success Criteria | See individual Success Criteria | |
| 64 | 2.4.1 Bypass Blocks | A | Web design/content best practice, can easily be implemented in Terminalfour Page Layouts. | Implementation advice | A link is provided to skip navigation and other page elements that are repeated across web pages. | |
| 65 | 2.4.1 Bypass Blocks | A | Web design/content best practice, can easily be implemented in Terminalfour Page Layouts. | Implementation advice | If a page has a proper heading structure, this may be considered a sufficient technique instead of a "Skip to main content" link. Note that navigating by headings is not yet supported in all browsers. | |
| 66 | 2.4.1 Bypass Blocks | A | Web design/content best practice, can easily be implemented in Terminalfour Page Layouts. | Implementation advice | If a page uses frames and the frames are appropriately titled, this is a sufficient technique for bypassing individual frames. | |
| 67 | 2.4.2 Page Titled | A | Web design/content best practice and can be locked down in the Page Layout. | Implementation advice | The web page has a descriptive and informative page title. | |
| 68 | 2.4.3 Focus Order | A | Web design / content & use of Terminalfour best practice. | Implementation advice | The navigation order of links, form elements, etc. is logical and intuitive. | |
| 69 | 2.4.4 Link Purpose (In Context) | A | Web design/content best practice. | Implementation advice | The purpose of each link (or form image button or image map hotspot) can be determined from the link text alone, or from the link text and its context (e.g., surrounding paragraph, list item, table cell, or table headers). | |
| 70 | 2.4.4 Link Purpose (In Context) | A | Web design/content best practice. | Implementation advice & Content: General | Links (or form image buttons) with the same text that go to different locations are readily distinguishable. | |
| 71 | 2.4.5 Multiple Ways | AA | Web design/content best practice. | Implementation advice | Multiple ways are available to find other web pages on the site - at least two of: a list of related pages, table of contents, site map, site search, or list of all available web pages. | |
| 72 | 2.4.6 Headings and Labels | AA | Web design/content best practice. | Implementation advice | Page headings and labels for form and interactive controls are informative. Avoid duplicating heading (e.g., "More Details") or label text (e.g., "First Name") unless the structure provides adequate differentiation between them. | |
| 73 | 2.4.7 Focus Visible | AA | Web design/content best practice. | Implementation advice | It is visually apparent which page element has the current keyboard focus (i.e., as you tab through the page, you can see where you are). | |
| 74 | 2.4.8 Location | AAA | Web design/content best practice. Breadcrumb navigation can be added to all pages. | Implementation advice | If a web page is part of a sequence of pages or within a complex site structure, an indication of the current page location is provided, for example, through breadcrumbs or specifying the current step in a sequence (e.g., "Step 2 of 5 - Shipping Address"). | |
| 75 | 2.4.9 Link Purpose (Link Only) | AAA | Web design / content best practice. | Content: General | The purpose of each link (or form image button or image map hotspot) can be determined from the link text alone. | |
| 76 | 2.4.9 Link Purpose (Link Only) | AAA | Web design / content best practice. | Content: General | There are no links (or form image buttons) with the same text that go to different locations. | |
| 77 | 2.4.10 Section Headings | AAA | Web design/content best practice with these being able to be locked down at a Content Type or Page Layout level. | Content: General | Beyond providing an overall document structure, individual sections of content are designated using headings, where appropriate. | |
| 78 | 3 | Understandable: Content and interface are understandable | NA | See individual Success Criteria | See individual Success Criteria | |
| 79 | 3.1 | Readable: Make text content readable and understandable | NA | See individual Success Criteria | See individual Success Criteria | |
| 80 | 3.1.1 Language of Page | A | Can be added in a Page Layout when using Terminalfour in multi language mode. | Implementation advice | The language of the page is identified using the HTML lang attribute (<html lang="en">, for example). | |
| 81 | 3.1.2 Language of Parts | AA | Can be incorporated into a Content Type formatter when using Terminalfour in multi-language mode. | Content: General | The language of page content that is in a different language is identified using the lang attribute (e.g., <blockquote lang="es">). | |
| 82 | 3.1.3 Unusual Words | AAA | Web design / content best practice. | Content: General | Words that may be ambiguous, unknown, or used in a very specific way are defined through adjacent text, a definition list, a glossary, or other suitable methods. | |
| 83 | 3.1.4 Abbreviations | AAA | Content: General | Expansions for abbreviations are provided by expanding or explaining the definition the first time it is used, using the <abbr> element, or linking to a definition or glossary. NOTE: WCAG 2.0 gives no exception for regularly understood abbreviations (e.g., "HTML" on a web design site must always be expanded). | ||
| 84 | 3.1.5 Reading Level | AAA | Web design / content best practice. | Content: General | A more understandable alternative is provided for content that is more advanced than can be reasonably read by a person with roughly nine years of primary education. | |
| 85 | 3.1.6 Pronunciation | AAA | Web design / content best practice. | Content: General | If the pronunciation of a word is vital to understanding that word, its pronunciation is provided immediately following the word or via a link or glossary. | |
| 86 | 3.2 | Predictable: Make Web pages appear and operate in predictable ways | NA | See individual Success Criteria | See individual Success Criteria | |
| 87 | 3.2.1 On Focus | A | Web design / content best practice. | Implementation advice | When a page element receives focus, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user. | |
| 88 | 3.2.2 On Input | A | Web design / content best practice. | Implementation advice | When a user inputs information or interacts with a control, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time. | |
| 89 | 3.2.3 Consistent Navigation | AA | Web design / content best practice. | Implementation advice | Navigation links that are repeated on web pages do not change order when navigating through the site. | |
| 90 | 3.2.4 Consistent Identification | AA | Web design/content best practice and the consistency can be locked down using Page Layout and Content Type formatters. | Implementation advice | Elements that have the same functionality across multiple web pages are consistently identified. For example, a search box at the top of the site should always be labeled the same way. | |
| 91 | 3.2.5 Change on Request | AAA | Web design / content best practice. | Implementation advice | Substantial changes to the page, the spawning of pop-up windows, uncontrolled changes of keyboard focus, or any other change that could confuse or disorient the user must be initiated by the user. Alternatively, the user is provided an option to disable such changes. | |
| 92 | 3.3 | Input Assistance: Help users avoid and correct mistakes | NA | See individual Success Criteria | See individual Success Criteria | |
| 93 | 3.3.1 Error Identification | A | There is an issue logged as RDFB-370. This will make it easier to meet this guideline. | Implementation advice & Content: Forms | Required form elements or form elements that require a specific format, value, or length provide this information within the element's label. | |
| 94 | 3.3.1 Error Identification | A | There is an issue logged as RDSM-25786. This will make it easier to meet this guideline. | Implementation advice & Content: Forms | If utilized, form validation errors are presented in an efficient, intuitive, and accessible manner. The error is identified, quick access to the problematic element is provided, and the user is allowed to easily fix the error and resubmit the form. | |
| 95 | 3.3.2 Labels or Instructions | A | In Form Builder forms, when dependencies are set and fields are shown and then hidden an explanation should be given to the user either via a paragraph of text or via a descriptive label. | Implementation advice & Content: Forms | Sufficient labels, cues, and instructions for required interactive elements are provided via instructions, examples, properly positioned form labels, and/or fieldsets/legends. | |
| 96 | 3.3.3 Error Suggestion | AA | In Form Builder forms validation messages can be set so the forms can be WCAG compliant. There is an issue logged as PM-1669 to allow the messages to be customized. | Implementation advice & Content: Forms | If an input error is detected (via client-side or server-side validation), provide suggestions for fixing the input in a timely and accessible manner. | |
| 97 | 3.3.4 Error Prevention (Legal, Financial, Data) | AA | A core part of Terminalfour. All changes are audited and version controlled. | Governance | If the user can change or delete legal, financial, or test data, the changes/deletions can be reversed, verified, or confirmed. | |
| 98 | 3.3.5 Help | AAA | Best practice when building a form. | Implementation advice & Content: Forms | Provide instructions and cues in context to help in form completion and submission. | |
| 99 | 3.3.6 Error Prevention (All) | AAA | A receipt can be generated and returned to the user via email to confirm. | Implementation advice & Content: Forms | If the user can submit information, the submission is reversible, verified, or confirmed. | |
| 100 | 4 | Robust: Content can be used reliably by a wide variety of user agents, including assistive technologies | NA | See individual Success Criteria | See individual Success Criteria | |
| 101 | 4.1 | Compatible: Maximize compatibility with current and future user agents, including assistive technologies | NA | See individual Success Criteria | See individual Success Criteria | |
| 102 | 4.1.1 Parsing | A | Testing within the system should support this. Once validated the HTML can be locked down using Page Layout and Content Type formatters. | Implementation advice | Significant HTML/XHTML validation/parsing errors are avoided. Check at http://validator.w3.org/ | |
| 103 | 4.1.2 Name, Role, Value | A | Testing within the system should support this. Once validated the HTML can be locked down using Page Layout and Content Type formatters. | Implementation advice | Markup is used in a way that facilitates accessibility. This includes following the HTML/XHTML specifications and using forms, form labels, frame titles, etc. appropriately. |