Skip to main content

Accessibility in OutSystems Web Applications

OutSystems

Accessibility in OutSystems Web Applications

OutSystems is committed to allowing the development of enterprise-grade applications that meet the highest accessibility standards and guidelines. With OutSystems 11, you can build WCAG 2.0 AAA, Section 508 and ADA compliant web applications faster, by leveraging a set of out-of-the-box accessible UI components. You also have full freedom to extend the language and create the custom rich, accessible patterns and interfaces you need, by editing HTML markup and ARIA Roles using pure low code or traditional HTML and CSS.

While the accessibility of any application built with OutSystems ultimately depends on the developers and how they implement images, links, forms, headings and all other instances of content, this article shows you some best practices and guidelines you can follow as well as how you can leverage the out-of-the-box accessible development accelerators OutSystems provides.

To learn more about accessibility, see Web Accessibility Perspectives Video (YouTube) or read Accessibility Fundamentals. This document helps you implement accessibility in your OutSystems applications by adhering to the rules in WCAG 2.0 and WCAG 2.1 to reach the different levels of accessibility.

Guidelines for implementing accessibility

The following set of guidelines along with the standards and best practices guide by Web Accessibility Toolkit will help you in developing more accessible applications.

Have readable text with the correct contrast

Font-size, text-color and background-color have huge impact on applications if they do not follow the WCAG guidelines for contrast accessibility.

When starting a style guide or building stylesheet rules for a pattern, make sure that:

  • Text under 24px should have a minimum color contrast ratio of 4.5:1
  • Text 24px or higher should have a minimum color contrast ratio of 3:1

Learn more about accessible colors or generate a color palette based only on background color and level of accessibility in Color Safe Website.

WCAG rules achieved:

1.4.1 - Use of Color (Level A)

1.4.3 - Contrast (Minimum) (Level AA)

Use heading elements correctly

Use headings correctly to organize the structure of your content and allow effective navigation through information.

Convert a container or placeholder to a heading using the tag "OSTagName" on "Extended Properties".

Create a new CSS class to style the text of heading elements.

Learn more about heading markup.

WCAG rules achieved:

1.3.1 - Info and Relationships(Level A)

2.4.1 - Bypass Blocks (Level A)

2.4.6 - Headings and Labels (Level AA)

2.4.10 - Section Headings (Level AAA)

Provide alternative text to images

Set the alt attribute to make images more accessible.

In the Label property of the image, set the alt attribute to make it accessible.

The resultant HTML is as follows:

<img src="sample_image3.png" alt="Clear Coded Programming" title="Clear Coded Programming" width="150" height="150">

If an image does not convey any actual information and is only present for decorative purposes, hide it from screen readers in the Label property by making the alt attribute empty (alt="").

The resultant HTML is as follows:

<img src="sample_image3.png" alt="" title="" width="150" height="150">
<img src="sample_image3.png" width="150" height="150">

To use images inside a link or as buttons, set the alternative text to describe the link's destination or the button's purpose.

Learn more about making images accessible.

WCAG rules achieved:

1.1 - Text Alternatives (Level A)

1.4.5 - Images of Text (Level AA)

1.4.9 - Images of Text (No Exception) (Level AAA)

Make sure that the destination of links in applications is correctly described. Using "click here" is not considered to be appropriately descriptive and is ineffective for screen readers.

For instance, if you are pointing users to a page called "Security Policies":

When using links:

  • Never use the word "link" or "click here" in your links. When a screen reader reads it, the user does not have any context.

  • Avoid capitalized links wherever possible. Some screen readers read capitalized text letter-by-letter and it is hard to read for people with reading disabilities.

  • Avoid using URLs as the descriptive text for links. When a URL is present as a link, a screen reader would read it letter-by-letter, thus making it difficult for the user to understand and interpret the information.

Make animated content accessible

To animate and change the visibility of animated elements, change opacity: 0 to opacity: 1 and use the visibility property to make sure that the element is not readable through screen readers. This results in a smooth animation.

.tooltip.is--hidden {
    opacity: 0;
    visibility: hidden; /* hide from assistive technologies */
}

.tooltip.is--visible {
    opacity: 1;
    visibility: visible; /* make visible to assistive technologies */
}

WCAG rule achieved:

2.1.2 - No Keyboard Trap (Level A)

Removing the outline using :focus { outline: none; } violates accessibility rules.

If you must remove the outline, always provide alternative styling.

/* remember to define focus styles! */
:focus { outline: 0; }
:focus { outline: thin dotted; } /* Style the outline */
:focus { background: #FFFF00; } /* Give it a background colour */
:focus { color: #FF6600; } /* Change the text colour */
:focus { outline: #FF0000 dotted medium; } /* Provide a custom outline */
:focus { color: #FFFFFF; background: #FF0000; } /* Go high visibility */

Another solution is to create a CSS class called no-focus-outline and add it to the <body> element. Add the keyup EventListener to the body and when an end-user presses the Tab key, remove the class no-focus-outline.

CSS:

.no-focus-outline a:focus,
.no-focus-outline button:focus {
    outline: none;
}

JavaScript:

document.body.addEventListener('keyup', function(e) {
    if (e.keyCode == "9") /* tab keycode */ {
        document.body.classList.remove('no-focus-outline');
    }
});

Learn more about outline: none.

WCAG rules achieved:

2.1.2 - No Keyboard Trap (Level A)

2.4.7 - Focus Visible (Level AA)

Have accessible application templates

The two types of default application templates in OutSystems UI - the TopMenu and the SideMenu - are accessible, making sure that they are interpretable by the browser and the screen reader.

HTML Semantics used: <header>, <nav>, <aside>, <main>, <footer>

ARIA Roles used: role="banner" (header), role="navigation" (nav), role="complementary" (aside), role="main" (main), role="contentinfo" (footer)

Have accessible keyboard interaction

One important aspect of accessibility is keyboard accessibility. It is essential for people with disabilities and useful for all.

OutSystems UI has implemented accessible keyboard interaction in the UI Web Patterns.

Used Keycodes: Space(32), Enter(13), ArrowLeft(37), ArrowTop(38), ArrowRight(39), ArrowDown(40), Escape(27)

Patterns: Accordion, Alert, Balloon, Carousel, LightBoxImage, DatePicker, Dropdown, DropdownSelect, FloatingActions, NavigationBar, SectionIndex, Tabs, Tooltip, ResponsiveTableRecords, FlipContent

For other interactive elements, you can implement accessible keyboard interaction as follows.

  1. Add keydown or keyup event listeners to the interactive elements.

    element.addEventListener('keydown', myKeyboardInteractionFunction);
    element.addEventListener('keyup', myKeyboardInteractionFunction);
    
  2. Set the keycodes to enable interaction.

    // if the user presses the Space key (keyCode: 32) or the Enter key (keyCode: 13)
    if (e.keyCode == "32" || e.keyCode == "13") {
        //code here
    
        e.preventDefault();
        e.stopPropagation();
    }
    
    //if the user presses the Escape key (keyCode: 27)
    if (e.keyCode == "27") {
        //code here
    
        e.preventDefault();
        e.stopPropagation();
    }
    

WCAG rules achieved:

2.1.1 - Keyboard (Level A)

2.1.2 - No Keyboard Trap (Level A)

2.1.3 - Keyboard (No Exception)(Level AAA)

Have accessible expandable and collapsible elements

Patterns with hidden and collapsible elements must be handled using a custom script so that the change of view states are accessible.

OutSystems UI Web Patterns has implemented accessible expandable and collapsible elements.

Commonly used ARIA states: aria-hidden, aria-expanded, aria-controls, aria-labeledby, aria-label, aria-valuenow, aria-valuemin, aria-valuemax

Patterns: Accordion, Tabs, Alert, Tooltip, Dropdown, FloatingActions, NavigationBar, FlipContent

For other expandable or collapsible elements, you can change or set Aria states as follows.

// Set visibility through ARIA states

var setAriaState = function(element, ariaAttribute, ariaValue) {
     element.setAttribute(ariaAttribute, ariaValue);
};

// Call the function to change ARIA to specific elements

setAriaState(elementWrapper, 'aria-expanded', 'true');
setAriaState(elementItem, 'aria-hidden', false);

Set the tabindex for accessible navigation

The tabindex attribute specifies the tab order of an element when the Tab key is used for navigating. In the Extended Properties of the required element, set the tabindex value. This ensures that the order that is read in the screen readers is the order of the DOM.

Learn more about accessible usage of tabindex.

WCAG rules achieved:

2.1.1 - Keyboard (Level A)

2.1.2 - No Keyboard Trap (Level A)

2.4.3 - Focus Order (Level A)

2.4.7 - Focus Visible (Level AA)

3.2.1 - On Focus (Level A)

Extend Containers and Placeholders to implement accessibility

These widgets are powerful elements for developers to implement accessibility in their applications. You can make containers and placeholders work as HTML tags. To do this, add OSTagName = "<html_tag>" as an Extended Property.

You can also extend these elements to receive ARIA roles, ARIA states, ARIA properties, tabindex or change things based on variables on your screen.

Web accessibility tools and references

You can use the following tools and references to check if your OutSystems applications comply with accessibility guidelines.

WCAG guidelines

WCAG 2.0 and WCAG 2.1 are sets of stable guidelines that developers need to follow to make their content accessible to everyone (with and without disabilities).

HTML and ARIA extensions

The use of non-semantic elements such as <div> and <span> with a class attribute are not understandable by accessibility tools. Using HTML semantics clearly describes the meaning to browsers, developers and screen readers, and guarantees the accessibility of the content.

These are a few examples of HTML semantics:

<aside>, <figure>, <figcaption>, <footer>, <header>, <main>, <nav> , <section>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>

See the HTML Semantics cheat sheet to learn more.

To have a readable structure that is accessibility compliant, implement HTML semantics whenever possible. When not possible, use ARIA as an extension of HTML so that it is fully accessible.

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) has roles, states, and properties to help developers describe the meaning of content and works as an extension of HTML. It allows developers to add specific attributes to HTML tags (such as alert or slider).

See the ARIA roles, ARIA states & properties and ARIA Landmarks to learn more.

Accessibility for teams

The following links act as a 'quick-start' guide for embedding accessibility and accessible design practices into your team’s workflow.

Evaluation tools

You can evaluate the accessibility of your content using the following tools.

Screen readers

You can test if your application is completely readable using these test screen readers.

Color and contrast checkers

WCAG has guidelines for contrast accessibility to help UI / UX designers and developers to achieve different levels of accessibility. You can use the following checkers to validate the implementation of those guidelines in your applications.

For more accessibility tools, check out this collection of web accessibility tools and the W3 evaluation tools list.

  • Was this article helpful?