This article contains:

Perceivable

1.1 Text Alternatives

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

1.1.1 Non-text Content

All img tags must have alt attributes.

All images to have meaningful alternative attributes assigned.
E.g. Risk Rating images

If short alt text is sufficient to describe an image, provide the short text via the image's alt attribute.

Short alternative text are applied to images.

E.g. Risk Rating - High

If a short text alternative is not sufficient to describe an image (such as in a chart, graph, or diagram), provide short text via the image's alt attribute, and include a long description in nearby text.

Descriptive text are included if short alt text is not enough.

If an image or icon is used as a button or link, the image has a text alternative sufficient to describe the purpose of the button or link.

No images will be used as buttons or links. But font icons will be used. aria-labels are used to describe the font icons for screen readers.

Images that are decorative, used for formatting, or contain content already conveyed in text have a null alt attribute or are implemented as CSS background images.

Decorative images are introduced as background images.

E.g. Product Menu images are displayed as background images.

Frames and iframes have descriptive titles.

Meaningful titles are included in iframes throughout the application.

E.g. Title="Project Details Page"

Minimise the number of adjacent links to the same destination by combining adjacent images and text into a single link, rather than creating a separate link for each element.

Only one link will be used for a specific link or destination in the application.

1.2 Time-based Media

Provide alternatives for time-based media.

1.2.1 Audio-only and Video-only (Prerecorded)

For pre-recorded audio (without video), provide a descriptive transcript that includes dialogue and all other meaningful sound.

Not applicable for Camms products.

For pre-recorded video (without audio), provided a text alternative or audio descriptions that provide the same information presented.

Not applicable for Camms products.

1.2.2 Captions (Prerecorded)

Provide captions for prerecorded audio content in non-live synchronised media.

Not applicable for Camms products.

1.2.3 Audio Description or Media Alternative (Prerecorded)

For non-live video, provide a descriptive transcript or an audio description.

Not applicable for Camms products.

1.2.4 Captions (Live)

Provide captions for live audio and video.

Not applicable for Camms products.

1.2.5 Audio Description (Prerecorded)

Videos should include "radio style" narration so that content makes sense if someone is consuming just the audio track. Include any text elements in the narration.

Not applicable for Camms products.

1.3 Adaptable

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.1 Info and Relationships

Use semantic markup to designate headings, lists, figures, emphasised text, etc.

Headings and subheadings are marked with H1, H2…H6 tags. <em> and <strong> tags will be used to mark emphasised or special text.

E.g. <H1>Project Settings</H1>

Organise pages using properly nested HTML headings.

Heading tags in pages are nested in a proper order.

Use ARIA landmarks and labels to identify regions of a page.

Camms applications contain specific areas for different purposes in a single page. Adding ARIA landmarks to these areas will help assistive technology users to easily navigate to various sections of a page.

E.g. Left navigation area, Risk Heatmap area.

Reserve tables for tabular data, use table headers appropriately, and use table captions.

Tables will only be used for displaying tabular data with column headers, which will also assist screen readers to speak the header information.

E.g. Project Register Grid.

When the appearance of text conveys meaning, also use appropriate semantic markup.

Semantic markups are used to relevant content.

Avoid emulating links and buttons. Use the a and button tags appropriately. Avoid using a tags for buttons. Avoid using div, span, etc. tags for links or buttons.

No emulations used for anchor tags & buttons.

E.g. Use of strong, em tags.

Avoid using whitespace characters for layout purposes.

White spaces in characters are avoided as it can impact screen reader functionality.

1.3.2 Meaningful Sequence

Ensure that the source order presents content meaningfully. When the page is viewed without styles, all content on the page should still appear in a meaningful and logical order.

Page content is arranged in a meaningful sequence to assist assistive technologies.

1.3.3 Sensory Characteristics

Do not identify content based on its colour, size, shape, position, sound, or other sensory characteristics.

Additional information provided along with colours to assist visually impaired users.

E.g. - 'Off Track' text for Progress areas with colours.

Do not convey information solely through icons or symbols.

Additional information is provided along with images to assist visually impaired users.

E.g. - Rating images with High, low text.

1.3.4 Orientation

All content and functionality should be available regardless of whether a mobile device is oriented vertically or horizontally, unless the orientation of the device is absolutely essential.

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape.

1.3.5 Identify Input Purpose

If a form field asks for information about the user and if there is an appropriate HTML autocomplete attribute, include that autocomplete attribute.

Not applicable for current controls. Will be implemented if autocomplete is used in the future.

1.4 Distinguishable

Make it easier for users to see and hear content including separating foreground from background.

1.4.1 Use of Colour

Links should always be easily identifiable through non-colour means, including both default and hover states. The easiest and most conventional way to signify links is underlining.

Hyperlinks throughout the application have their default visual standards, in order to be identified easily. (Underline)

Required fields and fields with errors must include some non-colour way to identify them.

Input errors will be displayed in text where assistive technologies can use to identify and provide error information to the user.

E.g. 'Please enter description'

When the colour of words, backgrounds, or other content is used to convey information, also include the information in text.

Text information is provided along with colours to convey information.

E.g. 'Percentage Complete'

1.4.2 Audio Control

Do not have audio that plays automatically on the page. When providing audio, also provide an easy way to disable the audio and adjust the volume.

Not applicable for Camms Products.

1.4.3 Contrast (Minimum)

Text (including images of text) have a contrast ratio of at least 4.5:1. For text and images of that is at least 24px and normal weight or 19px and bold, use a contrast ratio that is at least 3:1.

Colour contrast ratio of 4:5:1 is maintained throughout the applications for text as people with low vision often have difficulty reading text that does not contrast with its background.

1.4.4 Resize text

Ensure that there is no loss of content or functionality when text resises.

When zoomed, content will still be accessible.

1.4.5 Images of Text

Avoid images of text, except in cases such as logos.

No images of text are used. Exception is logos uploaded by client for the header area.

1.4.10 Reflow

Provide responsive stylesheets such that content can be displayed at 320px wide without horizontal scrolling. (Content which must be displayed in two dimensions, such as maps and data tables, may have horizontal scrolling.)

Content made responsive except for controls such as data grids, graphical charts which enable horizontal scrolling. These are exceptions to this criteria.

1.4.11 Non-text Contrast

Colour contrast for graphics and interactive UI components must be at least 3:1 so that different parts can be distinguished.

Graphical elements of controls, maintain a 3:1 contrast ratio against adjacent background colours.

E.g. Input border colour A toggle to be provided to the user to change certain colours to comply with 3:1 standards.

When providing custom states for elements (E.g. hover, active, focus), colour contrast for those states should be at least 3:1.

Colour contrast ratio of 3:1 provided for hover, active, focus events on controls.

E.g. Button hover colour.

1.4.13 Content on Hover or Focus

For tooltips, follow corresponding ARIA authoring practice.

Tooltip roles and aria attributes are set which helps assistive technology.

For content that appears on hover and focus: the content should be dismissible with the escape key; the content itself can be hovered over; and the content remains available unless it is dismissed, it is no longer relevant, or the user removes hover and focus.

For contents that appear on hover and focus, can be closed by pressing the escape button.

E.g. Tooltips.

To the extent possible, content that appears on hover or focus should not obscure other content, unless it presents a form input error. Or can be dismissed with the escape key.

Additional content shown in hover or focus does not obstruct other content. Hover/focus items to be dismissed with 'escape' button.

Operable

2.1 Keyboard Accessible

Make all functionality available from a keyboard.

2.1.1 Keyboard

Avoid implementing access keys. When access keys and other keyboard shortcuts are implemented, they must not interfere with existing browser and screen reader provided shortcuts.

No access keys are introduced.

All functionalities should be available to a keyboard without requiring specific timing of keystrokes, unless the functionality cannot be provided by a keyboard alone.

All functionality of the content is operable through a keyboard interface.

Avoid relying exclusively on pointer-driven events, such as onmouse over, to provide functionality when scripting. Generally, such functionality will also require scripting for keyboard operability.

Onmouse over functionalities are reduced.

In general, avoid using scripts to remove focus from an element until the user moves focus manually.

No scripts will be used to remove focus from controls.

2.1.2 No Keyboard Trap

Ensure keyboard focus is never trapped on an element without an obvious way to move focus out of the element. Make sure the user can move focus to and from all focusable elements using a keyboard only.

Ensure that controls or content does not 'trap' keyboard focus.

2.1.4 Character Key Shortcuts

If a keyboard shortcut uses only letters (including upper- and lower-case letters), punctuation, number, or symbol characters, then the user must be able to disable the shortcut, remap the shortcut, or limit the shortcut to only when a particular interactive element has focus.

No keyboard shortcuts will be used.

2.2 Enough Time

Provide users enough time to read and use content.

2.2.1 Timing Adjustable

Do not require time limits to complete tasks unless absolutely necessary. If a time limit is necessary, the time limit should be at least 20 hours, or it can be extended, adjusted, or disabled.

Timeouts can be extended in the applications.

E.g. Session timeouts.

2.2.2 Pause, Stop, Hide

Items on the page should not automatically move, blink, scroll, or update, including carousels. If content does automatically move, blink, scroll, or update, provide a way to pause, stop, or hide the moving, blinking, scrolling, or updating.

No automatic scrolls, blinks used.

2.3 Seizures and Physical Reactions

Do not design content in a way that is known to cause seizures or physical reactions.

2.3.1 Three Flashes or Below Threshold

Do not provide any content that flashes more than three times in any 1-second period.

No flashy content displayed more than 3 times in a second.

2.4 Navigable

Provide ways to help users navigate, find content, and determine where they are.

2.4.1 Bypass Blocks

Provide a link to skip to the main content as the first focusable link on the page.

Upon visiting a page by keyboard, a 'Skip to main' link is provided for the user to directly navigate into the main content area. By adding this link, screen reader users do not have to go through all header links.

2.4.2 Page Titled

Make sure each web page has a title tag that is descriptive, informative, and unique.

Descriptive titles used as it allows a user to easily identify what Web page they are using.

E.g. Risk Types page in the Settings area has a descriptive title 'Define and update multiple risk types here, which can then be linked to a hierarchy node or an entity to create risks...'.

2.4.3 Focus Order

Create a logical tab order through links, form controls, and interactive objects.

Default tab index are set to content so that tab navigation is meaningful and in correct order.

E.g. Navigating from one control to the adjacent control in a form.

When inserting content into the DOM, insert the content immediately after the triggering element, or use scripting to manage focus in an intuitive way. When triggering dialogs and menus, make sure those elements follow their trigger in the focus order in an intuitive way. When content is dismissed or removed, place focus back on the trigger.

Focus on elements inside controls such as dialog windows, menus are set once these are triggered. Once the user leaves the dialog window, focus will be back on the trigger element.

Avoid using tab index values greater than 0.

All tab index values are set to 0 to avoid unnecessary focus.

2.4.4 Link Purpose (In Context)

The purpose of each link can be determined from the link text alone, or from the link text and the containing paragraph, list item, or table cell, or the link text and the title attribute.

All links are provided with meaningful text or title attributes.

E.g. 'Attach Document' link in workflow menu.

2.4.6 Headings and Labels

Ensure that on each page, headings, landmark labels, and form labels are unique unless the structure provides adequate differentiation between them.

All headings and labels are unique in a given page. This will help users to understand what information is contained in Web pages and how that information is organised.

2.4.7 Focus Visible

Provide keyboard focus styles that are highly visible, and make sure that a visible element has focus on all times when using a keyboard. Do not rely on browser default focus styles.

Outline focus with a high colour contrast ratio provided to focused elements inside a page. Purpose of this success criterion is to help a person know which element has the keyboard focus.

2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

2.5.3 Label in Name

The accessible name for a UI element must contain any visual label for the element. Accessible names for UI elements should match visual labels as closely as possible.

Accessible names for form controls will be the same for it's relevant labels. This helps speech input users to clearly identify a form controle with its label.

E.g. Having attribute 'for=firstname' for the label 'First Name' which identifies its textbox with id=firstname.

2.5.4 Motion Actuation

Avoid activating functionality through motion (e.g. shaking a phone). If motion triggers functionality, provide a way to disable the motion trigger, and provide an alternative way to activate the functionality.

Not applicable to Camms products.

Understandable

3.1 Readable

Make text content readable and understandable.

3.1.1 Language of Page

Provide a lang attribute on the page's html element.

Objective of this technique is to identify the default language of a document. 'lang' attribute is set on all pages.

E.g. <html lang="en">

When a visual label is present for an interactive element (e.g. link or form control), the accessible name of the element should contain the visual label.

Accessible names for labels and controls are provided which is required to support assistive technologies.

3.1.2 Language of Parts

If a portion of the page is in a different language, use the lang attribute on that part.

Not applicable to Camms products.

3.2 Predictable

Make Web pages appear and operate in predictable ways.

3.2.1 On Focus

When the focus change, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user.

No changes in the page upon focus.

3.2.2 On Input

When a user inputs information or interacts with a control, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user. If an input causes such a change, the user must be informed ahead of time.

No changes in the page upon input.

3.2.3 Consistent Navigation

When a navigation menu is presented on multiple pages, the links should appear in the same order on each page.

Same navigation menus with the same links order will appear throughout the application.

E.g. Mega Menu which contains all navigational links inside the application, is displayed in same format on all pages.

3.2.4 Consistent Identification

When components have the same functionality across several web pages, the components are labeled consistently on each page.

All control related labels are labeled consistently.

3.3 Input Assistance

Help users avoid and correct mistakes.

3.3.1 Error Identification

Programmatically indicate required fields using the required or aria-required attributes. Also, visually indicate required fields in the form's instructions or form labels. Do not indicate required fields for CSS alone.

Required form fields are displayed by a colored indicator icon throughout the application. Also, aria-required attribute is set for relevant fields. 

Make errors easy to discover, identify, and correct.

Input errors are displayed in text clearly along with the control.

E.g. 'Please enter title' with textbox border highlighted in red colour.

Identify errors using aria-invalid.

Errors in input controls marked up with aria-invalid attribute. This will help assistive techonologies to identify inout errors easily.

E.g. <input type="text" aria-invalid="true".

3.3.2 Labels or Instructions

Use semantic, descriptive labels for inputs. Visually position labels in a consistent way that makes associating labels with form controls easy. Do not rely on placeholder text in lieu of an HTML label.

Form controls and relevant labels are placed in a logical order. Descriptive labels are used throughout the application.

When providing inline help text, use aria-described by to associate the help text with the input.

Help text for certain inputs, charts, etc. are conveyed through aria-described by attribute.

Robust

4.1 Compatible

Maximise compatibility with current and future user agents, including assistive technologies.

4.1.1 Parsing

Validate all page HTML, and avoid significant validation / parsing errors.

All pages are validated for HTML markups.

4.1.2 Name, Role, Value

Avoid creating custom widgets when HTML elements already exist. For example, use a and button tags appropriately.

No custom widgets created to replace standard HTML elements.

Use ARIA to enhance accessibility only when HTML is not sufficient. Use caution when providing ARIA roles, states, and properties.

ARIA attributes used on relevant elements.

4.1.3 Status Messages

When conveying a status message, use ARIA live regions or ARIA alerts to announce the message to screen reader users.

Alerts such as error messages will be associated with ARIA live attributes to be screen reader friendly.

E.g. Error message alerts.

Camms.Project

• About Us

• Add Projects Project Register

• Custom object

• Favourites

• Login

• Menu

• My Quick Update

• Project Board and Team object

• Project Register

• Sign Out

• Task Planning object

• User Guide

Camms.Risk

Camms.Risk Incident

Camms.Risk Compliance