ARIA Spec for the Uninitiated

[amazonv]

ARIA Spec for the Uninitiated

Type: Breakout

Track: Development

Specs are usually not very fun, but I have learned that reading the ARIA specs is important to fully understand all the various options that are available. In this presentation, I will walk you through the ARIA spec and show you how to make the most out of it to create custom components with ARIA.

 

[missed some]

 

for the uninitiated, I know you could have chosen other wonderful sessions at this time.  If you don't know me my name is Gerard K Cohen and engineering manager accessible person at Twitter.  You can check my website-- I'll have this information at the end just in case you missed it here.

The link to the slides are available at HTTPS--  bit.   Ly/2zc6TDf.  I'll show it in the end again just in case.

A few shout outs to my friends, if it you didn't get a chance to check it out today, catch the replays of something to nothing highway a team of two kicked off an accessible program and accidentsal advocacy when you don't realize you're steering the ship by Andrew.  And later on today I highly recommend you catch micro interactions, more like micro aggressions.  And you can't go wrong with any sessions in AxeCon.  Lastly thanks to the fine folkings at Deque for allowing me to speak today.

Wanted to take this opportunity to let you know I have accessible courses available on the plural site platform.   They are meeting web accessibility guidelines introduction to development components with ARIA and accessibility testing and screen reader use.  If you're interested in learning more from it me check them out at plural sight.   This presentation is mostly for in you users of ARIA I'll be walking through the documentation and show examples.  If you're been using--

Dangers of ARIA, official ARIA standard, pointing out important sections including the rules of ARIA.  Another resource is the ARIA authoring practices and discuss their proper use.  You should be well introduced to ARIA.

I'm going to demonstrate how to use the ARIA resources and finally walk through testing of the expand control by discussing the accessible tree and using the screen reader.

I want to explain why I felt like enter prosecuting this content.  Rl I feel ARIA has a bad rap.  * but accessibly vilified and understand why and a lot of the negative sentiment is warranted.  I won't deny that.  It can be misunderstood and abused and do serious damage to Assistive Technology users.

I think it's easier to say don't use it than to properly explain it and learn it it.  It's not going to help anyone.   At a certain point HTML is not enough.  ARIA shouldn't be an option, but when it is, it's your only consistency.  It's not perfect but you shouldn't be overly afraid of it and avoid it.  I recommend you take the time to learn and understand it.

I thought of something based on some noise in the CHAT room, apparently everyone's betting on how many times I mention the first rule of ARIA.  I'll randomly choose someone on Twitter the number of times I speak of the first rule of ARIA throughout this presentation.  I'll send you a prize.   Tweet me,--

With that being said let's start with the dangers of ARIA.   So I want to first talk about the dangers of ARIA why were it's important to know and use it right.  It's powerful and essential to providing the level of dynamics available in today's web.  Iewsing ARIA incorrectly and can cause-- and I've said ARIA should be a last resort basically to fill in the gaps that HTML has.

So why is ARIA so troublesome?  Besides people not taking the time to learn it properly is because ARIA supports  varies.  There are lots of hands in the pot.  Unfortunately ARIA's not always supported by browsers and Assistive Technology in the same way.  And ARIA supported sometimes there's bugs in the implementation.  What's frustrating it's different across all browsers-- some are not function is in another implement in -- sometimes they may break.  It's the same you would expect with webinar technologies.   Unfortunately there are no queries that you can query like  CSS or aability to test support.  The only thing you can do is test your work and provide work arounds.  You have to know what you're doing.  Throwing ARIA at the problem is not always a solution

To of pro that point, a survey in March of 2020 states home pages with ARIA present average 60% more errors than without ARIA.  The more ARIA is used the more errors the is found on the page.  It could be making things worse.  This is why there's a popular sentiment in the community that no ARIA is better than bad ARIA.  If you don't know how to use it, leave it off.  Hopefully you'll learn-- let's get into the documentation.

The official ARIA standard is the first resource.  Normally visiting the official standard or spec for web technology is reserved for the academic types.  Most of you have never read the script standard.  If you want to know what something means I urge you to come here first before  searching online.  As of this morning the latest version of the ARIA standard is 1.1.  You can get to the latest version by going to WW-- (READING).  Make sure you bookmark there.   If you want to do ARIA right, you'll reference it a lot.  I don't expect you to read the whole thing there are a couple of session I want to poit out that will serve as the basis of everything I talk about in this presentation and everything related to ARIA from now on.  Incidentally it's getting closer as it was promoted con date recommendation last week.  Today I'll use verse 1.1.  This version is section 5.3 categorization of rules which lists the available rules ARIA provides.  What are roles?  Roles are how you provide Semantic to elements and they're extremely important to accessibility it's the way you let someone know what it is.  And how it is to be used.  For example if I hand you on object and toll you it's a folk, you won't-- roles do the same thing and they are a contract between you and the user.  * once you provided a role you make sure the functionality and action that role is meant to provide.

The categorization of a role is key.  And there are four that I want to point out to you.

Starting with section a .3.2 widget roles, the roles you * indicate interactive elements broken down into two groups, stand alone and composite.  Stands alone operate on their own.  And there are 20 stand-alone widgets listed here some of which you may be familiar with button, check box or link.

* the next group are composite widget roles, parent roles or containers for other stand alone widget roles.  There's ate strict hierarchy with composite widget-- and often in a very particular order.  In most cases you cannot pick and choose which roles you compose to a widget.  Now let me repeat that because this is important.  There are very strict parent child relationship between certain roles some roles can be used as a child to composite role.  It's important to understand especially when with -- be very careful about how you nest components and role because you can be breaking your well intended accessibility if you don't respect the parent child relationship of rules.

I'll go relation Shiv of rules later.  Document trowct provides content organization.  These 26 document structure rules are not interactive but provide semantics like contents -- provided by HTML elements.

The nix group roles.  Not necessarily based on direct user interaction.  They don't need to be actively focused "user in order to be announced.  Some examples of content that would be considered a good use are sports scores, CHAT logs, timers or dynamic error merging.  Live regions are important and heavy used in today' dynamic web applications but can be a Bowlesed and overused.  I want you to be aware of them anyway.

The last group of roles are window roles.  And these are-- there are only two of them, window roles are considered ton dynamic in window pop-ups.  These can be composite widget role except they have especially meaning in terms of document structure.

*

Okay, finally and alphabetical rerns of all the available roles is listed in section 25.4, definition of roles.  * 5.4.  Another mart is section 6 on support thed states and properties specially on global states and properties and 6.5 which is the taxonomy on why ARIA.  Section-- it lists in categories.  For example widget attributes and relationship attributes.

Section 6.6 is an alphabetical listing of ARIA states and properties and I'll go over the usage later when I demonstrate how to build an expandable widget.  So if you're paying close attention you noticed I skipped the section on landmark roles.  They do not require ARIA.  When you have the need to express these roles you should be using the HTML counterpart.  What's the big deal of using them if they're available?  That's a great question to ask leading into the next section of the five rules of ARIA.

So when it comes to ARIA there are five established rules you need to be aware of.  High level rules in guiding you to when you develop your ARIA widgets.  The first rule is-- if you have started on your journey in ARIA, the first rule is don't use ARIA.  ARIA can definitely can cause fights.  If you're confused by this rule it's because it's not accurate.   This is an incomplete rule.  The entire rule is, don't use ARIA if you can use HTML instead.  As I mentioned in the overview of the ARIA standard it's used to describe widget roles and covered by HTML properties.  If you can use HTML counterpart first and supported by browser and Assistive Technology you're better off using HTML as it will provide all properties like ARIA while providing a table experience.

For example, going back to the ARIA landmark rules as demonstrated here most of these have HTML tags.  So instead of roam of banner, you should use the header tag, instead of role = complimentary, use aside.  Roam forming is form, and role = main is main.  Role = navigation is the that. AV tag.   * we'll talk more about accessible names in a little bit especially with the fifth rule of ARIA.

Role equals contact info is the same as the footer.  And the only one that doesn't have the associated tag is landmark.  When they were first fraused they advised to use the tag and ARIA role-- the HTML tag is widely supported.  If you make it a practice to value date your markup which you should you'll get an error not to double up on the Semantics.  You might get the same error if you do automated accessibility testing depending on the tool you use

The second rule of airplane air is don't change native semantics.  If you use HL7 first, make sure you don't use ARIA to change the semantics.  Many if you *.

The ARIA role takes precedence over the HTML.  Rule * note

Let's say your site or application has a collapsed menu and using a link because it's easy to style and natively  provides focussability which you heard was good for accessibility.  Make the page jump when had the link is used and you display your menu.  At some point you learn that links are meant for navigation and you should use a button for this but don't want to modify your markup foreign CSS.   You learned about * ARIA roles.  And you decided add the role of button.  If doesn't make sense to you right now, don't worry.

So what is the problem with adding the role in this way?   Well as you may have already learned role semantics are a contract.  The elements needs to behave as expected by the role.  But links don't account act the same as buttons,  links are activated using the-- you so to fix this, you decide to add JavaScript and restore the contra and technically Assistive Technology might smooth over the usage of space versus enter that shouldn't change the guidance here.

At this point, considering all the work that you had to do hopefully you realized it would have been easier to use the button if you use HTML it will provide platform provided for you.  You use ARIA to fill in the gaps as necessary.

Hopefully the third rule of ARIA is familiar to you.  All interactive ARIA roles need to be operable by keyboard.  If functionality is via mouse or input, it also need to be by keyboard.  Keyboard support is absolutely fundamental or accessibility support.  Ensuring keyboard support will get you a long way with input modalities like game controller.   The fourth rule of ARIA is don't use role = presentation or ARIA hidden equals true:  It removes the semantics of an element-- Assistive Technology user will not know what it is for and how to use it.  This could create a barrier.  ARIA hidden is a state that effectively hides it.  It describes things, when you're using ARIA hidden equals true it's rendered visible on the screen and it hides that element which create a serious barrier to users.

Proper ways to hide elements is a separate conversation but for now just know that role equals presentation and ARIA equals true is be dangerous if not understood and used properly.  The fifth and last rule of ARIA is all interactive elements must have an accessible name.  Why is this important?  I'm going to use a simple example.

Imagine you had a form with a few form elements.  Without an accessible name or label wall you're telling the user is input.  Input for what?  * what are they inputting?  One way and not necessarily the best way but one way would be to use the ARIA label property.  Now a user will know to provide the street address.  Again this is not actually the best way to provide an input label because it's not visible but we're talking a ARIA here.

So if semantics or roles give you the time then the accessible -- it's important for voice recognition user to identify and interact with controls on the page.  Make sure that all interactive elements have an accessible name.  The

The five rules of area are documented here at HTTP//www .. W.3.org-- (READING).

There's a lot of really good information documented on this page I encourage you to check it out more.

Another pornltdz resource that I want to discuss are the office ARIA authoring practices.  This resource is refer to as a sample of proper ARIA for various widgets.  The  authoring practices are available at-- (READING).  They demonstrate 27 different widgets and patterns.  They're interactive widgets that are only available via ARIA like tabs.  I'm going to use the accordion example because I wrote it because I'm familiar with it it.  Each pattern starts with information about the general purpose and usage which can include variations.  I'm going to skip over the example and go over the keyboard interaction section.  Included is the keyboard interaction which describes the element and expected result.  For example, with the accordion, when focuses on accordion, enter or space should essentially toggleling whether or not the accordion is expanded.  Expectations for tab and shift tab and up and down arrows and home and-- a also included.

* after the keyboard support section is a section that lists all the the necessary ARIA roles.  Everything you need to know in terms of implementing this pattern is listed here.   Now, to experience this in real life, let's go back to the example provided.  All the example is follow the same outline.  They start off with link at the top and introduction of the example and how the pattern is  implemented.  I'll get back to the links in a bit.

After that is a live working implementation of the pattern that you can play with and test.

After the example is usually a description or explanation of various accessibility features implemented.  While not always specific to ARIA it's good guidance to follow.  It explains how to helps-- enhanced keyboard navigation is provided.  Following that is the keyboard support  implemented.  This breaks down the expected keys peopled and the expected interactions.

And then a more detailed description of the roles states and properties and tab index in the pattern.  This is a mapping of HTML element to attributes using the example.

To rounds out the example are links to the CSS and JavaScript file and the Nark up used.  Maybe you're thinking of skipping the rest of the presentation-- not so fast.   These are used in a way that are not originally intended and often used incorrectly.  I want to point out noticed in the documentation.

In the very beginning of this section I talked about the links at the top.  And point out some things mentioned in the browser and Assistive Technology page.  This is really important.

The page states, testing Assistive Technology interoperability is essential before using code from this guide in production.  Because of the purpose of this guide is to I wills operate appropriate use of ARIA 1.1 as defined in the ARIA specification, these design-- (READING).  Do not describe and implement coding techniques for work being around problems caused by gaps (READING).

It is thus advise able to test complementations thoroughly with each browser (READING).

It goes onto say, and pept in cases (READING) specific Assistive Technology are demonstrating browser or Assistive Technology bugs.  (READING) and that is from the ARIA  authoring practices document 2 it .2 browser and Assistive Technology support with add ed emphasis by me.

What does that long quote mean?  * what it's saying is they don't provide guidance how to work around bugs.  It's actually a testing tool for browsers and AT vendors to beef up support.

The truth of the matter is ARIA is only a speck.  There's no guarantee that browser vendors and Assistive Technology are going to support it just the way building codes.  They advise testing everything before using.  One more note I want to point out here.  Currently this guide does not indicate which examples are compatible with mobile browsers while some of the examples include-- enhance mobile and touch support some ARIA.  There's not a standard Idessed approach for providing touch approach.  And this is from the ARIA document section 2.3 mobile and touch support (READING) this is an acknowledgment that these pattern may not be supported by mobile browsers.  The design patterns-- this is future work to be done.  Be aware that doesn't always guarantee accessibility.  Things need ton tested.

I'm not telling you you can't use the patterns.  You can use them as a basis for your widgets.  The point is test, test, test.  Everything you do and not just on your own hopefully with real userred you'll discover inconsistencies and fill in the gaps.  That's why it's important to know and understand ARIA and not copy and paste these patterns.

All right.  I got a time check.  I'm 40 slides left.   (READING).  (READING).

And this is from the ARIA authoring practices 1 # .5.2.  Not just relying on the inclusion of ARIA to-- a lot of times they'll deviate from the first rule of ARIA and use roles and properties available via HTML.  In order to test ARIA they have to use all of ARIA.  I'm not saying don't use the resource, just test everything yourself.  Follow the keyboard interaction and start with the rules and experiment with falling back to using HTML and make sure you can test everything with Assistive Technology.

Now I'm going to build on top of the principles I talked and dive into code for expandable component.  Called collapse or collapsable.  I'm going to call it expandable.

I'll start with an example of FAQ page.  Base odd not the experience, I'll demonstrate semantics.  In this case I'm using my mouse and clicking on the title to expand.  Let me try the same FAQ with the screen reader and demonstrate so you can have an idea what the screen reader might go  through.

>> First thing tab be skips over FAQ.  Luckily screen reader have other ways to navigate a page in this case I can use the arrow keys to navigate.

>> Heading level two--

>> Okay, so I found a heading formatted as a question.  Let me see what happens when I use the space key, nothing.   Enter key nothing.  Space and enter are conly used to perform a quick action.  Obviously something is wrong here and an Assistive Technology may not get the answer to the questions.  So bringing the screen back, let me talk what happened.  This FAQ is not keyboard operable.  I'm tabbing through the page and I'll not able to get to the FAQs.  This means without an Assistive Technology running a keyboard only user would not be able to access the answers and this is breaking the 30 rule of ARIA and WCAG guidelines.  Using the screen reader I was able to find something but not indication who to do.  * when I try to perform the quick action, nothing happened

So hopefully you all know that semantics are huge for accessibility.  Semantics expressions what something is.   Oncer you know what it is you know how to use it.  What is the respected result from using that thing?  Semantics play an important part and concept when it comes to accessibility of widgets.  Every intercontrol must provide the following three things.

Flame, role and value.  Of these three things semantic provides the role.  This is where we get into ARIA the air one dot two-- the roles are for document structure and-- and even a role generic described as a nameless container element with no semantic meaning.  It's --

So these 70 roles in version one dot one, only 29 are interactive roles.  Let's go back to the ARIA standard and see what we can find.

So here's once again the ARIA standard, there are 29 available widget roles these are the roles available in  ARIA.  You cannot make up your own roles.  So looking at these 29 rules any one of them-- I'll look at the first one, the button rule.  Rule provides definition and information-- here's the existing code with the FAQ title with the heading level two.

I'm going to add the rule equals button to the H2 and test this.

>> And a halving to the first FAQ announces as a button which is great.  I'm giving users an indication what it is.   I can use it to get to the answer.  But it doesn't work.   Now this is an important lesson in ARIA and semantics.   Roles don't provide interaction they describe what it is but don't provide the behavior semantics are a contract with the use once you tell what something is they know how to use it you need to honor the contract.  Even though I added the role of button this thing is not complete.  Not only that by doing this I broke the first three rules of ARIA.  As the a review the first rule is don't use ARIA if you can use HTML instead.

The second rule of ARIA we broke as well by putting the the role button on the H2 we replaced the H2 semantics-- the third rule is the FAQ is themselves were not accessible by keyboard.

We can throw a lot of code at this like adding a tab index and key down events for enter and space and that would complete the button.  I'm going to show you a quick fix.

All I'm going to do wrap the HT with the button and move the FAQ class over to that button.  That's it.  Small change with a huge impact.  Let's test this and see how to works.   Now I can access each one of the tabs and FAQ by tab and how about that contract?  * I've expanded FAQ using pace and enter key and it works.

(READING).  This is why accessibility professional stress learnling HTML so much.  It does the heavy lifting for you.   I know it's easier than it sounds, and it can be hard to know when it out HTML versus ARIA.  I'm working on a  periodic table.  This period ignorance table is every HTML available.  Many if you need to provide semantics you can find out if there is an HTML you can use if not you can fill in had the gap using ARIA you can find this at (READING).

Going back to the FAQ control, I'm not using any ARIAthis is -- this is a present AIG ARIA.  But for the goal of this exercise, providing semantics we don't need ARIA yet.  Don't use ARIA if you can use HTML.  (READING).  There's a gap here that we need to fill.  Interacting with the button produces a change on the screen, expands and collapses the answer since the main focus of accessibility is to provide-- to do that I need ARIA statements.  We have ten minutes  left.  I have a few more slides left.  If you don't mind let me get through this quickly.

Thank you.  Thank you so much.  Along with providing semantics ARIA provides states and properties to describe interfaces to Assistive Technology.  We will learn and apply them to'ing fantastic.  Going back to the three things they need name role and value ARIA helps provide name role and value and extremely important to accessibility because dynamic changes must be presented programmatically.  This is what ARIA states and properties provide.  As of ARIA 1.1, there are 48 states and properties.  Let's look at the available states-- back to the official standard 6.6 definition of states and properties there are 48 that are available and just like the roles you cannot make up your own statements and properties.  There are rules about which states and properties can be applied to specific roles some are required on certain roles and some are not supported or allowed.  Considering there's a large set of options and a limited way and set to apply them, how do you figure out the right one to use?  We can check back to the role define in his will find out.  Each role definition includes this table of characteristics.  And here are supported states and properties.  There were two states and properties allowed on the button role one is the ARIA expanded.  I'm going to select it to get more information.

So ARIA expanded it describes whether the element or  groupling element and controls is expanded or collapsed.  Just like roles each definition includes a table of characteristics.  And here's the roles used in role section where you see all the roles that this particular state supply.  As confirmation the button is listed and expanded property.  I'm going to update the markup and add ARIA expanded on the bottom-- (READING) and I won't go over it-- you can use whatever you want.  The important thing is the markup is rendered in the browser and that's what you use and assist assist interact with.  The markup has to be right.  So now the ARIA expanded state will let Assistive Technology know this can be expanded and collapsed.  And this is perfect.  We have a proper role proper interaction and communicating the state change.  We can see all of this by inspectioning the accessibility tree.

*less tree is a subset of the Dom tree.  It's easy to inspect accessibility tree and browsers.  I'm going to run through this real quick using chrome.  In in the inspector I'm going to open the accessibility panel and check out the accessibility tree information.  You can look at the  computed property.  Here it's listed as collapse.  If I expand it it changes to tree.

But that's not enough you have to make sure you test with Assistive Technology.  And even though the accessibility tree offers a quick way, you should test with some kind of Assistive Technology.  I'm going to run through the fix FAQ page with voice over so we can hear the difference and experience.

 I'm going to tab down to the FAQs.  And it announces a button.  We know it's collapsed.  And the fact that this control is announced and collapsed let's the user know there will be additional information when expanded.   I'll expand FAQ and can you'll hear the information.  All right.  So this is a successful implementation.  In the end all it took was correct HTML for Shen ticks and yun ARIA property.-- I was able to provide the necessary experience without abusing ARIA.  Sometimes you don't internet too much ARIA but other complex cases you may need to go full ARIA.   So in summary, don't be afraid of ARIA.  Familiarize with the specs and use it when it's only to fill in HTML gaps.   It's more importantly not when to use it.  No matter what you do, make sure you test everything.  Thank you for attending.  The slides are at HTTP-- bit.ly/2Zc6TDf.  You can reach me at Gerard Cohen.  Don't forget about the contest.  I'll son.  Now for questions.

>> Just a couple of questions here.  * I think we have five minutes or so.  So I will go with the ones that received most uploads.  Tons of questions.  It you so much Gerard.   Okay, so when you are ARIA live to update dynamic content how do you deal when you have multiple updates offer the page that needs object announced for example changing your age on the form updates your monthly premium and say, above your focus points on two separate areas within your page.  *

>> You're changing a field and there's dynamic information updated above or below?  I'll just answer both ways.  If it's below, technically you don't have to use the live region to announce they want.  They're in the flow of the document.  If it's above, maybe a science change.  But you had prioritize the updates that are happening.  Maybe combine them so there's one announcement but definitely you need to be careful with updating too much because you keep in mind that those announcements will interrupt or try to sneak?  While the user is typing.  So it can be very chatty.   So if you can make a design change to have that information lower or maybe there's a review page that can happen that would be my recommendation rather than try to fix it on the ARIA level fix it in the design level.

>> When would you want to use ARIA hidden = true?

>> Oh, there's actually good cases for that.  And let's see sometimes for example when using -- I'll use ARIA hidden = true for SPGs to provide ALT sex for SVG-- text rendered on the page.  That's one way to use it.

>> * what tools do you recommend for validating the  semantics of HTML?

>> That's a good question.  You can always -- the W3C has  in.  U.-- you can search NU validator.  That will give you-- there's obviously node plug ins that you can use, I believe axe, the automated testing tool does the validation as well.

>> Yep.  Awesome.  One last question here can you give an example of how an AT user can suffer from bad usage of ARIA?

>> Again, so not providing the right semantics.  I use an example of adding a role of button.  Abuse of live regions is prevent lent.  Many too things announced at the same  time.  * it's hard to listen to that.  And hiding content when it's not supposed to be hidden is another one.

>> Got it.  Awesome.  Well, I do apologize for any questions or all the questions that we weren't able to get to.  Everybody was very engaged.  Thank you so much for your time for this great content the Tuesday for attending this session we have a handful more left in AxeCon so I hope you enjoy the rest of it.

>> Have a great one.  Thank you, everyone.

>>