Creating accessible web apps sometimes feels like a daunting task. But as we’ve shown in our previous post of this series, it’s time to take accessibility seriously. At OutSystems, we’re committed to helping you on your journey to build accessible web apps. This is why we recently delivered several accessibility development accelerators to make it easier to quickly build accessible apps. Here you’ll find exactly how you can do it.

What’s New For Accessibility in OutSystems?

In the latest version of OutSystems UI, we made available more than 70 accessible patterns, widgets, and screen templates for our most recent reactive model. This means that it’s now easier for developers to build web apps that conform to accessibility standards.

Our UI patterns come with HTML semantic tags and preconfigured ARIA roles and can be interpreted by the browser and by assistive technologies. They also include built-in keyboard navigation, a key element in adding an extra dimension to the page interactions, and one that is fundamental to accessible interfaces.

Because not all interfaces are the same, we’ve also made sure you can build any custom, rich, and accessible patterns you need. You can do this with low code alone - by turning lower-level patterns into business-specific, rich, and accessible reusable UI blocks -  or by using the many UI extensibility points available in the platform, such as:

  • Low-code styles (Styles Editor)
  • HTML markup
  • ARIA roles
  • HTML and CSS code

This means that there are no barriers in your journey to WCAG 2.1 AA compliance, even if you want to build non-standard interfaces and patterns.

Web accessibility compliance

Accessible Application Layouts

Most application templates have a simple layout with four sections: header, navigation, main, and footer. To make them accessible, developers must make sure the content in each section is readable and identified.

Accessible Apps Layout

These sections are where we’ll add the interactions and the content for each screen. We’ve properly declared and structured the code, the template’s sections are identifiable and isolated, and the CSS classes are assigned to the elements in the CSS and the DOM.

But there’s a problem. Assistive technologies, such as screen-readers can only interpret textual content in the structure. So for these technologies these elements can represent anything, from pens to chairs to anything else.

When laying out the structure and content of the page, the developer has only declared the CSS classes on those elements, our CSS style sheet paints the elements and positions them on the screen. It's an acceptable solution for a standard user, but it’s useless for assisted technologies and is therefore not accessible to all.

So What’s the Answer?

It lies within HTML semantic tags and ARIA roles. They identify the elements within the structure, serving as landmarks to help users understand the layout of the page/screen. In OutSystems UI, all screens are created from pre-built application templates with built-in accessible layouts.

Without changing a thing, browsers and screen readers can relay the layouts correctly. They know precisely where the headers, footers, navigation, and main content is. And this means that you can extend these templates with HTML semantic tags and ARIA roles, adding your content in compliance with the WCAG 2.1 guidelines (we explain these concepts in the first blog post of this accessibility series).

The HTML semantic tags and ARIA roles included in the layouts, correctly identify the content in each area:

  • HTML semantic tags: <header>, <nav>, <aside>, <main>, <footer>.
  • ARIA Roles: role="banner" (header), role="navigation" (nav), role="complementary" (aside), role="main" (main), role="contentinfo" (footer).

These are included by default in the OutSystems UI patterns, so that you can build web apps that are compliant to WCAG 2.1, level AAA by applying the proper configuration and techniques to achieve compliance (more on that in a moment).

Together with these UI patterns, we’ve also crafted many convenient, reusable UI blocks to speed-up application development. You can find all the available UI patterns on the OutSystems UI website, and all the features and behaviors for each pattern in the OutSystems UI Live Style Guide.

Because building accessible interfaces is more than using the right elements on a web-page and hoping it’s compliant, in the next sections we’ll look at some techniques and best practices you need to apply to ensure all the apps and UI patterns you’re building are assistive-technology ready.

Accessibility Guidelines and Best Practices

There are many accessibility guidelines and best practices, and diving deep into them surpasses the purpose of this article. However, to give you a head start, I’m going to share some of the most recurrent and challenging ones.

Make Links Accessible

Follow the general usability guidelines; if the link is non-textual, like an image, you should add alternative text instead, making the purpose of the link explicitly clear, so that screen readers can relay to the user what they can’t see. The general usability guidelines are:

  1. Hyperlink meaningful text: The purpose of a link should be clear from the link text alone. The user should easily decide if they want to follow the link. Read more about writing hyperlinks in this Norman Nielsen Group article.
  2. Make links obvious: The user shouldn’t have to search for the links, visual cues tell the user where the link is. Users are used to seeing blue text as clickable, the location of the link is also a visual cue for the user, for example, text inside a menu, or along the peripheral areas of a page or screen. If you use buttons, make sure they look like buttons, prefer 3D-like buttons, flat buttons are harder for the user to recognize.
  3. Be consistent: Pick a hyperlink design and use it throughout your application.
  4. Visited links: Make sure users can identify the links they have visited. You can do this by toning down the color or by making the link red.
  5. React to mouse-over: On mouse-over the link should change its style (color, size, etc.), letting the user know that it’s clickable (web only).
  6. Add padding: Not everyone has slim, precise fingers, to help mobile users tap. Add padding to enlarge the selectable area.

WCAG Rule Achieved:

2.4.9 Link Purpose (Link Only) (Level AAA)

Make Forms Accessible

Forms are just about everywhere - they are, after all, the most cost-effective way to collect information from users. As such a vital part of an application, it’s essential to build them with accessibility in mind. Failing to do so will increase the risk that your users get lost in the form, and either input the wrong information, complain they cannot complete the form, or simply drop-out. 

The simplest way to make a form accessible is to use explicit labels that describe the form elements and to group related form controls. Using explicit labels improves screen readers’ text-to-speech intelligibility, and grouping related form controls helps users to focus on smaller groups of information, making forms easier to use.

Example of explicit labels:

<label for="name">Name:</label>
<input id="name" type="text" name="textfield">

Example of grouped form controls: 

<fieldset>
<legend>User details</legend>
<label for="firstname">First Name:</label>
<input id="firstname" type="text" name="textfield">
<label for="lastname">Last Name:</label>
<input id="lastname" type="text" name="textfield">
...
</fieldset>

To make a form accessible in OutSystems, all you need to do is drag the Form widget into a screen and then drag the entity to the form you’ve just created. Then you should group the form controls using the HTML Element widget and set “fieldset” on the tag attribute. You can also add the legend using the same technique, dragging the HTML Element to your screen and set “legend” on the tag attribute.

To take your form accessibility even further, have a look at Forms concepts. You can also use a form to group widgets.

WCAG rules achieved:

1.3.1 Info and Relationships (Level A)

2.4.6 Headings and Labels (Level AA)

3.3.2 Labels or Instructions (Level A)

4.1.2 Name, Role, Value (Level A)

Keep Smooth Transitions

Unfortunately, screen readers can’t interpret animations. As with images, web accessibility standards recommend that animations are hidden from assistive technologies, and, if they are not only for decorative purposes, they should be described in text form.

Animations are an excellent example of how building for accessibility can sometimes impact how your application looks. To animate elements and change their visibility, you could use “display: none” and “display: block,” but this removes your smooth transitions. You can, however, preserve the smooth transitions by using a few CSS tricks.

Smooth transitions

For smooth transitions, we’ll need to change the visibility of the element (bell icon) using “opacity: 0” to “opacity: 1” but it won’t be hidden from screen readers. So we need to hide the element from the screen readers, and for this, we’ll use the “visibility” property.

WCAG guideline achieved:

2.1.2 - No Keyboard Trap (Level A)

Push HTML Element, Containers and Placeholders to the Limit

HTML Element, Placeholders and Container widgets are powerful resources for accessibility, and they are low-code chameleons. In the HTML Element widget you can use any HTML tag, such as headings (h1 to h6), order lists (ol, ul, li) or figure captions (figure, figcaption). Take a look at HTML elements reference to know more.

The elements can also receive ARIA roles, states, properties, and the "tabindex" attribute, extending these elements, or even changing things based on variables on your screen or actions. Take a look at the following examples.

HTML Elements

The “tabindex” attribute has three types of use:

  1. Tabindex=”0” is used to maintain the natural tab order. When the Tab key is pressed the focus order will reflect the natural tab order. If the elements have an identical attribute, they are navigable according to how they are rendered on the page (DOM order).
  2. Tabindex with a value greater than 0 explicitly defines an order for the content. Explicitly setting the tab order is always a bad practice. When we try to navigate from one tab to another, the focus order will jump around the screen, confusing the user.
  3. Tabindex=”-1” is used to remove the natural tab order, meaning the focus can be set to the element through scripting focus() method.

Use Focus Order for Accessible Navigation

“If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)” - W3C.

This is one of the rules to achieve Level A compliance on your application. The default tab order provided by the DOM positions the elements in the DOM. To set the element’s tab position explicitly, you can use the tabindex HTML attribute.

In OutSystems you can add a specific tabindex, using the attributes in containers and placeholders if you want assistive technology to stop and read your content when tabbing.

Tabindex

Learn more about the usage of tabindex, and learn how to set the tabindex for accessible navigation in OutSystems in our documentation.

WCAG rules achieved:

2.4.3 Focus Order (Level A)

2.1.1 Keyboard (Level A)

2.1.2 No Keyboard Trap (Level A)

2.4.7 Focus Visible (Level AA)

3.2.1 On Focus (Level A)

Reaching Your Accessibility Goals

Level AAA conformance to WCAG 2.1 is the web accessibility gold standard, and if you’re looking to reach this level, you’re an accessibility champion! The higher the level of compliance, the greater the difficulty.

At this point, you probably just want to get started. With so many rules and guidelines, it can be hard to know where to start. My advice is that you start with testing.

There are many web accessibility evaluation tools that will point out your accessibility irregularities:

  • Web accessibility testing tools
  • Screen readers
  • Color and contrast checkers

The tools speed up your understanding of what you need to improve. Test frequently and narrow down your web accessibility conformance violations until you reach your accessibility goals. Our knowledge base article includes a select list of guidelines and best practices, so you can dive straight in and start building accessible apps with OutSystems.

Accessibility Matters, Let’s Roll up our Sleeves   

There are many benefits to removing any barriers and enabling everyone to access and use your web content. Your content, services, information, are accessible to all without limitations.

It’s time for a mindset shift! Developing for all levels of ability is good for business and reputation, and it’s also a contribution to building a better world! With OutSystems, we’ve made it a lot easier to build accessible apps, so why not get started with a free personal environment?