This document discusses accessibility with OutSystems. It begins by defining accessibility and its importance for developers and organizations. It discusses how to make applications accessible by following guidelines like WCAG and using semantic HTML, ARIA roles, and accessible UI patterns in OutSystems. Images, animations, outlines, containers, and screen templates can all be made accessible with the right techniques. Accessibility benefits everyone by enabling full participation on the web.
2. | Accessibility with OutSystems
Bruno
Marcelino
Front End Software Engineer | OutSystems
R&D
@
in
brunoap.marcelino@outsystems.com
/bmarcelino
/bmarcelin_o
@bmarcelino
4. | Accessibility with OutSystems
“The power of the Web is in its universality.
Access by everyone regardless of disability is
an essential aspect.”
Tim Berners-Lee, Director of the W3C (World Wide Web Consortium)
and inventor of the World Wide Web
5. | Accessibility with OutSystems
The impact of disability is different on the
Web, because the Web removes some of
the barriers.
6. | Accessibility with OutSystems
Accessibility is essential for
developers and organizations
10. | Accessibility with OutSystems
1/5 people have disability
The world population is almost 7.7 billion and
people with disabilities represents one in five people
12. | Accessibility with OutSystems
Increase the positive
image
High quality and flexible
application
Improve SEO
Improve usability
Build positive public
relations
Avoid discrimination and
legal complications
Benefits
19. | Accessibility with OutSystems
Web Content
Accessibility Guidelines
WCAG
HTML
Semantic Elements
HTML WAI-ARIA
Web Accessibility
Initiative – Accessible
Rich Internet Applications
+
20. | Accessibility with OutSystems
WAI-ARIA
Web Accessibility Initiative –
Accessible Rich Internet
Applications
Web Content
Accessibility Guidelines
WCAG
HTML
Semantic Elements
HTML +
22. | Accessibility with OutSystems
rules to achieve Level A
78
30
rules to achieve Level AA20
rules to achieve Level
AAA
28
WCAG
Guidelines
23. | Accessibility with OutSystems
SummaryGuidelines
1.3.2 – Meaningful Sequence
2.1.2 – No Keyboard Trap
2.4.3 – Focus Order
3.1.1 – Language of Page
Present content in a meaningful order
Don’t trap keyboard users
Logical order
Page has a language assigned
25. | Accessibility with OutSystems
HTML
Semantic Elements
HTML WAI-ARIA
Web Accessibility
Initiative – Accessible
Rich Internet Applications
Web Content
Accessibility Guidelines
WCAG +
26. | Accessibility with OutSystems
States & Properties
WAI-ARIA
Roles
HTML
Semantic Elements
27. | Accessibility with OutSystems
Semantic
Elements
HTML
<aside> <figure> <figcaption> <footer>
<header> <main> <nav> <section>
<h1> <h2> <h3> <h4> <h5> <h6>
28. | Accessibility with OutSystems
Roles
States &
Properties
WAI-ARIA
Progressbar Button Form Region
Group Search Headings Article
Document Presentation Toolbar
aria-invalid aria-pressed aria-required
aria-hidden aria-current aria-expanded
aria-haspopup
32. | Accessibility with OutSystems
<div id="demo" class="button" onclick="myFunction()">
Click to change text color to black!
</div>
<script>
function myFunction() {
document.getElementById("demo").style.color = "black";
}
</script>
33. | Accessibility with OutSystems
<div id="demo" class="button" onclick="myFunction()" tabindex="0"
role="button" aria-pressed="false">
Click to change text color to black!
</div>
<script>
function myFunction() {
document.getElementById("demo").style.color = "black";
}
</script>
With WAI-ARIA
34. | Accessibility with OutSystems
<button id="demo" class="button" onclick="myFunction()" aria-
pressed="false">
Click to change text color to black!
</button>
<script>
function myFunction() {
document.getElementById("demo").style.color = "black";
}
</script>
With HTML Semantics
35. | Accessibility with OutSystems
<button id="demo" class="button" onclick="myFunction()" aria-
pressed="false">
Click to change text color to black!
</button>
HTML
<div id="demo" class="button" onclick="myFunction()" tabindex="0"
role="button" aria-pressed="false">
Click to change text color to black!
</div>
WAI-ARIA
Comparison ARIA vs HTML Semantics
60. | Accessibility with OutSystems
var onAlertCloseClick = function () {
// Change ARIA state
alert.setAttribute('aria-hidden', 'true');
};
var onAlertCloseFocus = function () {
// Change ARIA state
alertClose.setAttribute('aria-hidden', 'false');
};
Alert
UI Pattern
61. | Accessibility with OutSystems
//Set keyboard interaction
var onAlertOnKeypress = function (e) {
if (e.keyCode == "27") {
onAlertCloseClick();
//prevents the default action the browser makes on that
event.
e.preventDefault();
// stops the event from bubbling up the event chain.
e.stopPropagation();
}
};
Alert
UI Pattern
86. | Accessibility with OutSystems
a { outline: none; }
:focus { outline: none; }
DON’T DO IT!
OUTLINE
Make it accessible
87. | Accessibility with OutSystems
2.1.2 No Keyboard Trap (Level A)
2.4.7 Focus Visible (Level AA)
OUTLINE
Make it accessible
88. | Accessibility with OutSystems
Notice the comment that says "remember to define
focus styles!" - ignorance is no excuse.
OUTLINE
Make it accessible
/* remember to define focus styles! */
:focus { outline: 0; }
89. | Accessibility with OutSystems
: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 */
Provide alternative styling!
OUTLINE
Make it accessible
90. | Accessibility with OutSystems
document.body.addEventListener('keyup', function(e) {
if (e.keyCode == "9") /* tab keycode */ {
document.body.classList.remove('no-focus-outline');
}
}); JS
.no-focus-outline a:focus,
.no-focus-outline button:focus {
outline: none;
} CSS
Add a no-focus-outline CSS class to the <body> element.
OUTLINE
Make it accessible
92. | Accessibility with OutSystems
OSTagName
CONTAINERS & PLACEHOLDERS
Make it accessible
To generate HTML tags around elements, use a Container or
Placeholder Widget and add OSTagName = "<html_tag>" as an
Extended Property.
93. | Accessibility with OutSystems CONTAINERS & PLACEHOLDERS
Make it accessible
Headings
Paragraph
94. | Accessibility with OutSystems CONTAINERS & PLACEHOLDERS
Make it accessible
Section
Article
102. | Accessibility with OutSystems SCREEN TEMPLATE
Make it accessible
Container
Button
Image
Text
103. | Accessibility with OutSystems SCREEN TEMPLATE
Make it accessible
Set Label property
104. | Accessibility with OutSystems
1.3.1 Info and Relationships (Level A)
1.3.2 Meaningful Sequence (Level A)
2.4.3 Focus Order (Level A)
3.2.3 Consistent Navigation (Level AA)
SCREEN TEMPLATE
Make it accessible
105. | Accessibility with OutSystems
Accessibility enables people to
access your applications,
without any limitations!
106. | Accessibility with OutSystems
Accessibility contributes
to building a better society!
Hi Guys first of all, thank you for attending this talk. As you can see, we’re here today to talk about Accessibility with OS
My name is Bruno Marcelino and i’m a Front End Engineer at OutSystems R&D. I’m part of the team that created SilkUI and OutSystems UI. These are my contacts and after this session, if you have any questions, feel free to contact me for more information.
Before we start talking about accessibility, first we need to understand web.
We all use the web on a daily basis, it has become part of how we do business, communicate, shop, learn. But how many of us have taken the time to think about what is Web and for who is the Web? So What is Web?
The Web is for everyone! It’s part of our everyday lives because it is universal.
It is designed to work for all people, whatever their tools to access it, software, language or ability.
When the Web meets this goal, it’s accessible to people with a diverse range of age, hearing, movement and cognitive ability.
On the web the impact of disability is different, because we can remove communication barriers and enable interaction between people. However, when applications or tools are badly designed, they can be the barriers that exclude people from using the web.
What kind of barriers are we talking about?
Well, we are talking about barriers to accessing our content, if we don't design for accessibility, the content may not be perceived by the user, or the content might not be read correctly by a screen reader, or, for example, the color contrast is not correct so the user can’t distinguish elements on a screen.
If we are to create high-quality applications, that don’t exclude people from using them, developers and organizations have to consider accessibility.
It is vital that our applications are accessible so that we can provide equal access and equal opportunity to people with all levels of ability.
Everyone gains from this, the organizations that want to offer a service, sell something, or provide information, and the users that wish to access those resources.
If you’re not providing an accessible application, then your customers will be missing out on revenue, because a part of the market will be excluded.
Our customers, and the digital world as a whole are increasingly concerned about this, when designing and creating apps. So “What is Accessibility?”.
With accessibility, all people can perceive, understand, navigate, and interact with the applications, with no limitations. In other words, accessibility is you building your tool or app so that it’s available to as many people as possible.
When we implement accessibility in our applications, we need to make sure that our apps describe the content for the screen readers and browsers.
I will explain this in more detail, further along, but first let’s clarify why accessibility is so important nowadays!
Now, take a moment and think about your friends and family.
I’m sure most of us know someone that needs to wear glasses, without them they can’t read or see much of anything at a distance.
And any one of us can have an accident, and be temporarily incapacitated.
We are all surrounded with accessibility issues, every day and most of us won't even notice!
There are a wide range of difficulties, some are only minor, like your friend with that wears glasses, but some create more barriers, like someone that is blind and cannot see at all.
There are about 1.3 billion people with a disability. This represents one in five people.
I was surprised when I learned this, before researching this, I also had no idea.
We all think that disabilities affect only a small percentage of the population but in reality, almost 20% of the world’s population in affected.
As the world population ages, this number will increase, so it’s time we all think seriously about this.
Governments are concerned about this and are requiring more and more that accessibility be provided to their populations, especially in educational and governmental applications.
There are already countries where it’s illegal to have a website that’s not accessible. For example in Norway, websites that don't comply will be fined.
And they do fine! For example, a company in Norway was fined around 15.000 euros PER day due to non-compliance.
So, now we have established that the Web is for everyone, and we know there’s are many reasons why we should seriously considering accessibility in our apps. But we still haven't identified our target audience. Who will benefit?
Usually when I talk about accessibility and ask someone about who it applies to, the first thing that comes to mind is that it’s only for the visually impaired, or blind people or for those with a physical disability.
But that’s the wrong answer!
An accessible web app must include ALL DISABILITIES that affect access to the Web, and this includes:
auditory, cognitive, visual, motor and speech.
These 5 categories define our main target audience but, in my opinion, there are other audiences who can benefit a lot from these changes.
Because an accessible application also benefits people without disabilities, benefit all of us.
Senior - We're all going to get old, hopefully. And as we get older, our capacities change.
Temporary disability - If we use glasses and lose them or if I walk out of here and get hit by a bus (you never knowww!), and imagine I end up breaking my arms, it’s going to be hard for me to use an application that isn’t accessible, right?
Slow Internet Connection - If our apps aren’t accessible, our content won't have much meaning. So we need to make sure that we add alternative text to images (alt or title), multimedia and other non-text objects.
Doing this means that people that have low bandwidth connections, and have disabled images and other media, can still understand the meaning of your content.
A lot of jobs like contact center, supermarket, commercial guy
Less luggage possible
Arrive to my client office earlier
Drop the laptop
Now we need to know how we can make our web content accessible. What is there to help us implement accessibility, What kind of techniques or technology exists?
Accessibility is based in 2 things:
Guidelines and development techniques, which are WCAG, ARIA and HTML.
WCAG - Is a set of guidelines that developers need to follow to make their content accessible to a wider range of people with (yes, and without) disabilities
WAI-ARIA - Are attributes that define ways to make Web content and applications more accessible.
HTML - Is a bunch of semantic tags that describe accurately the meaning of the content to browsers and screen readers.
These are our 3 major concerns when we implement accessibility in our applications
WCAG defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities and these guidelines cover a wide range of issues. It also helps us make Web content more usable to older individuals with changing abilities due to aging and often improves usability for users in general.
*https://www.w3.org/TR/WCAG20/
WCAG is based on 4 principals:
Perceivable - Information and user interface components must be presented to users in ways they can perceive it. Like, provide text alternatives for any non-text content.
Operable - User interface components and navigation must be operable. For example, making all functionality available from a keyboard.
Understandable - The Information in the UI must be understandable, and how to use the interface must be clear to the user. For example setting the language of the page, focus element, consistency of navigation.
Robust - Content must be robust enough so that it can be reliably interpreted by a wide variety of user agents, including assistive technologies.
*https://www.w3.org/TR/WCAG20/
For each guideline, there is testable success criteria. The test criteria requirements are distributed in three levels: A, AA, and AAA.
https://www.wuhcag.com/what-is-web-accessibility/
WCAG 2.1 will have additional requirements related to mobile accessibility.
Exist a draft of guidelines for mobile
Existing guidelines of wcag must be applied for mobile
For now only exists best practices and examples of mobile accessibility
Now we will talk about the development techniques
Semantic elements clearly describes its meaning to browsers, developers and screen readers.
ARIA has roles, states and properties to help developers describe the meaning of content.
WAI ARIA works as an extension of HTML, it provides an addition and manipulation of the HTML attributes in the tags of the HTML. This means that ARIA allows developers to add specific attributes to HTML tags (such as an article, alert, or slider).
When we combine these 2 technologies we make our content fully accessible and cross-browser / device-compatible.
These are only a few examples and the most used roles, states & properties of ARIA.
The roles never change in our applications because we use them to describe our content but it’s different for states & properties because we can change and manipulate them to change our elements in DOM to provide interaction in our content.
For example: modals. In most cases the modals are rendered in our page but they are hidden, and they only appear when a users clicks on something, like a button.
When a modal is hidden the default states and properties apply and when it’s open, we need to change it. This is a complex example but I simpler example to show you.
Let’s take a look to this example...all of you can see this square with a text?
Probably some of you can and others not.
This is unaccessible!
This is a simple page with an element.
The first thing that comes to your mind is “It’s just a button on a blank page?”
Yes it’s a button and I can interact with it because I can see where it is.
I know that the button will change it’s text color if I click on it. So I click on it to change the text color.
But we don’t know how the developer created it in the HTML.
We know there are different ways to create a button and not all are accessible.
Like this example.
This developer used a div to run a function.
We know that sometimes we do the same.
In this example, a browser or a screen reader doesn’t know what's in this element because a div is a non-semantic element, and doesn’t describe itself in a way that’s understandable.
Now you have all the context, I hope I haven't overloaded you with information.
However, it’s important that we are all on the same page when it comes to understanding accessibility. We must understand what we are trying to fix before setting out looking for a solution right?
We know that there’s really no way we can justify ignoring accessibility issues any longe. So with that said, how does OutSystems deal with Accessibility? And here’s where the magic of Outsystems UI enters the scene.
When we built our UI Framework, we knew that it was going to be used by thousands of developers, and we knew that everything we decided to do would impact you, our developers.
So, our UI Framework is split in two areas:
Templates
and Patterns
Let’s have a look at the most essential part of a app. The template!
Because without a template there are NO WEB APPS.
There are millions of applications all around the world. Anyone can access them, we’re talking about THOUSANDS of templates with all kinds of content, but they all have 4 things in common.
All the templates out there have, a: Header, Navigation, Main and Footer.
These are the most important areas of our template. The footer is probably the renegade of these 4 areas because sometimes it’s not used in applications.
The HEADER usually contains the app’s Logo, a search bar, the login information and a navigation menu.
The navigation menu can be located inside the HEADER or the SIDEBAR. The Main is the dominant part of our application, where all our content will be displayed on each screen. The Footer typically contains the navigation links, social links, company contacts, copyright data etc.
Besides being the most common, these areas are also the most important because they’re the areas in the app that’ll include the interactions and receive the content for each screen. The app’s template is the foundation that will be replicated in all the screens and it’s where we can guarantee that the content is properly described. So what does that mean?
(Parei aqui e assim que puder continuarei)
Most templates are built like in this example.
As you can see, everything’s correct, the code is properly declared and it has a good structure.
The CSS classes are attributed to the elements and the areas are created. But we have a problem with the readability and identification. The common user won't have any issues, they’ll be able to see the rendered structure of the page with no errors. But the browser or the screen-read wont be so lucky, the way it’s declared is the same as if...
It were a bunch of pens… or a stack of chairs.
These are classes to modify the element.
The browser only sees elements with classes (could be any elements right? Pens, chairs. And for screen reader it isn’t readable at all.
This structure only declares that the elements have those CSS classes, and our CSS stylesheet paint the element and position it in the DOM.
For the user who has no disability it’s all the same because what you see on the page is fine but those who need to have the page accessible to be able to use a screen reader, will feel lost.
To solve this type of issue and make an app accessible we need 2 things…
HTML semantic tags and ARIA roles.
With these, we make our content accessible and readable.
Using semantic tags and ARIA we guarantee the cross-browser /device-compatibility and we describe exactly what’s there to the screen readers and browsers.
OutSytems UI provides, 2 types of templates, by default.
The TopMenu and the SideMenu. These layouts are already accessible at a basic level guaranteeing that the browser and the screen reader can interpret them.
Providing an accessible template accelerates the development of accessible apps and saves the developer some time and worry.
Now we entry in the UI patterns
ProgressBar
Talk about the behavior options shape, size, orientation
ProgressBar
ProgressBar
HTML structure
Alert
Talk about the pattern behaviors and option
Message type
Show close button
Alert
Need to hide icons from screen readers
On focus change aria state
Alert
HTML structure
Alert
Event listeners
Alert
Reusable functions
Alert
Keyboard interaction - operable
Accordion
Talk about behaviors and options (disabled, open)
Accordion
Count all elements on accordion
Last element are disabled
Accordion
Expanded state
Accordion
Button and relationships
Accordion
HTML structure
Accordion
Keyboard interaction - operable
Accordion
Close key interaction
With OS UI we have accessibility by default but don’t forget...we can’t have our content fully accessible without developer.