[devnexus 2022] ARIA: A grande method of accessible markup

Speaker: Chris DeMars

Twitter: @saltnburnem

Link to table of contents

———————

General

  • low vision vs no vision
  • some types can be corrected and some cannot
  • memory problems included
  • Think about: hearing, visual, cognitive, movement and temporary
  • 1 billion people around the world have some type of disability
  • People don’t have to disclose they have a disability. Assume 20-25% do.

What is accessibility?

  • numeronym: a11y == accessibility
  • w3c – “people with disabilities can use the web”. better to say everyone can use the web
  • Don’t use accessibility overlays. [looked online – hack to use tool to patch bad accessbility]

ARIA

  • Accessible rich internet applications
  • Helps AT (assisted technology) with web pages
  • One rule: don’t use ARIA. Better to use semantic markup.
  • Stop using divs/spans unless have to. No semantic meaning. Better to be using header/nav/etc tags (vs h1/h2/etc heading level)
  • Anchor links for navigation only
  • When have to use div/span, add ARIA

Roles

  • abstract – command, input, landmark, select, structure, widget, etc
  • widget – button, link, option, radio, tab, textbox, etc
  • document structure – article, directory, figure, img, table, tooltip, etc
  • landmark – banner, contentinfo, form, main, navigation, search
  • live region (auto updating section) – alert, log, marquee, status, timer

States and Properties

  • States and Properties
  • describe what is happening
  • aria-describedby – if need to write a lot about what an image does
  • aria-haspopup
  • aria-label
  • aria-labeledby
  • aria-checked
  • aira-disabled
  • aira-required
  • etc

WAI/ARIA

  • Want to get to level AA.
  • Bank of America, Dominos, Red Roof In got sued for not meeting
  • Only get to AAA if in academia or government. Expensive. Ex: need closed captioning, ASL video, downloadable transcript, VPAS?
  • Want to get to level AA.
  • Bank of America, Dominos, Red Roof In got sued for not meeting
  • Only get to AAA if in academia or government. Expensive. Ex: need closed captioning, ASL video, downloadable transcript, VPAS?

Other notes

  • Don’t set outline to 0/none for focus. User needs that
  • https://caniuse.com
  • https://gist.github.com/chrisdemars/e8ca7a5282ab65ea2f412776a7cf0aa3

My take

The intro was good to pull me in. As were the examples of why to use semantic tags where can. The actual ARIA info felt a little like an info dump. I would have liked examples on a web page to see what these are/how they work. Or what the code looks like. Some was said out loud which helped. ARIA has changed a lot since I last used it. (so have front ends overall). The references to old tags like blink were fun.

intro to web accessibility

Someone asked me what someone should know/read as a crash course on web accessibility.  This seemed like too good a question not to blog about so he can read the answer here!

There are three main areas of web accessibility:

  1. W3C’s WAI (web accessibility initiative) has WCAG 2 (Web content accessibility guidelines) which are summarized on one page.  There’s a lot more to it than the one page, but it does represent the spirit.
  2. WAI also has ARIA (accessibility rich internet applications).  This is my favorite description.  Mozilla also has a good guide as does Opera.  In a nutshell, ARIA solves the problem of “how does a blind user know something on the page has changed.”  With AJAX and even DHTML, just because you made something available isn’t enough.  Be forewarned that older browsers have lousy ARIA support if any at all.
  3. Section 508 is in the same space as WAI except for government website.  It is part of the American with Disabilities Act.  It is more specific in some ways than WAI.  If you aren’t working on a government website, I’d focus on WAI.  Note that Section 508 is an OLD law and in theory they are working on a refresh.  I say in theory because I haven’t seen updates in a while.  There is a mapping in section 1194.22 between Section 5098 and the WCAG 1.0 guidelines.  Yes, 1.0.  Did I mention that Section 508 is old?  The government has free training.

The least you need to know for testing:

  • Make sure your application works without using a mouse.  Seriously, actually navigate your application without a mouse.  (Remember tab changes fields and space selects a checkbox.)  If it isn’t possible to use the application without the mouse, you have failed accessibility miserably.
  • Make sure you aren’t using color alone to convey information. Blind people will be using a screenreader and need alternate textual ways to derive this info. Colorblind can’t see the difference between red and green and won’t be using a screenreader so won’t see your alternate text.
  • Until you are REALLY familiar with how text only navigation works, use a screenreader emulator like the Fangs Firefox plugin and/or turn off stylesheets to see what your page looks like.
  • If you can afford a license for Jaws, it is helpful in testing that your application is accessible in practice and not just theory.

The least you need to know for coding:

  • For any image that conveys information, have an alt attribute.
  • Use form labels for all form elements so a screenreader can read what the form element is all about.
  • Use row and or column headers for all data tables so a screenreader can provide assistive text on where the user is in the table.  (And for the love pete, don’t complicate things with the navigation tables of the 90s)
  • I recommend automation to ensure you KEEP compliant.  It’s a pain to test this all once manually.  You don’t want to have to make sure the new person on your team remembered his/her alts.
  • Watch how you use JavaScript: Remember we need to work without a mouse.  That means an onchange handler in a pull down is the path to madness.  I want the fifth element so I tab to the field, choose the second, watch the page refresh, tab to the field again, choose the third, watch the page refresh and then decide never to do business with you again.
  • Some JavaScript libraries have accessible widgets.

“head first” style aria

I attempted to give a Head First style speech at the Toastmasters humorous speech competition. As a moderator at JavaRanch, it seemed fitting to put a transcript of one iteration online. While it changes a bit each time I give it, this is the idea.. Shown here with a bit of organization.

This was given to a largely non-technical audience.   For the more technical readers here, ARIA actually has four levels: off, polite, assertive and rude.  This article on ARIA is an excellent read.  My audience tells me the concepts were memorable and the speech was funny.  So I guess I accomplished my goal.  I did win at my club and get to go on to the next level.  Which gives me the chance to give this speech in front of people I don’t know.

You no longer have to imagine the sock puppets :).  I had two – one for the browser and one (with glasses) for the screenreader.
screenreader puppet

Anyway, here we go:


Introduction
Me: When you think of technology, do you think of humor?  I do.  My goal is to teach you about a technical topic called ARIA – Accessible Rich Internet Applications.  Boring?  Just you wait.  I brought sock puppets.

Welcome the characters
Me: We all know what a browser is.  We use it every day to browse the web.  I’ll let you imagine that this sock puppet is IE 7.  You may not know what a screenreader is.  Imagine you can’t see the screen.  What does our browser friend here look like?  Well, the screenreader reads the words in the browser to you.  The glasses remind us of reading so it will be easy to remember that this guy is the screenreader.  Lets listen in on how things worked up until now.

Scenario 1 – Before ARIA
Browser: I’m IE 7.  Who are you?
Screenreader: I’m a screenreader product called Jaws.
Browser: Ah!  A shark!  And I can’t see my users!  A shark ate my users!
Screenreader: Stop being so dramatic.  Your user is write here – safe and sound.  I help your user.
Browser: My user is just find without your help.
Screenreader: Want to be IE 7?  Watch what happens when a blind or vision impaired users tries to fill out a form without a standard called ARIA.
Browser: I’ll set the scene.  It was a dark and stormy night.
Screenreader: Get on with it.  I can’t read to the user until you get around to rendering the page.
Browser: Fine.  Here’s your page.
Screenreader: Ok.  User? I’ve got some questions on a form for you.  <hum as they go back and forth>
Browser: Uh oh.  The user entered a bad country.  I know because I checked with the website while the user was filling out the form.  I know!  I’ll put a big red message on the screen.  Surely the user will see that.
Screenreader: <back to humming>.  Submit.  My masterpiece.  All done now – time for a nap.
Browser: Wait a minute!  The country is still invalid.  Jaws – can sharks swim with their eyes close?  You’re falling asleep on the job.  I told you there was a message.
Screenreader: Did not!  You place a secret message and didn’t tell me it was there.  That’s like putting a note in a dictionary in a basement in Europe and claiming I should have seen it.
Browser/ Screenreader: Did not!  Did too!  Did not!  Did too!

Me: All right guys. Break it up.  Luckily this is a thing of the past.  Let’s upgrade to IE 8 and see how it looks now.  Ready IE 8?

Scenario 2 – Urgent Message with ARIA
Browser: Yes!  I’m all bright, shiny, new and upgraded.  My father was IE 7.  Parents are so backwards!  I’ll set the scene.  It was a dark and stormy night.
Screenreader: Just like you father.  Get on with it.
Browser: Where’s the fire?  Here’s your page.
Screenreader: <hum to user while fill out form>
Browser:  Uh oh.  The website says we can’t ship a book to North Korea.  I know!  I’ll set the rude ARIA property to tell the user.
Screenreader: I see the rube property is set.  The sky is falling!  The sky is falling!  I must tell the king, I mean the user.  User – Abort!  Abort! Urgent message – no books can go to North Korea.
Screenreader: Browser, that was a close one.  But we save the day – and the user – thanks to ARIA.  Remember what that stands for?
Browser: Yeah.  Accessible rich internet applications.  Accessible.  That would be you screenreader – reading to the user.  Internet Application.  That’s a website where we can fill out forms.  And rich.  That must mean the website has a pot o’gold.
Screenreader: Not quite.  Rich means dynamic and interactive.  Like gmail.  You can do things without reloading the whole page.

Interlude
Me: As you can see, IE 8 support is much better than IE 7.  But does this mean we have to interrupt the user for ever little thing.  Seems distracting.  T-O-P- Wait!  I have something unimportant to tell you. !  Let’s watch.  Browser?

Scenario 3 – Informational Message with ARIA
Browser: I’ll set the scene.  It was a dark and stormy night.
Screenreader:Oh for crying out loud!  Can’t we skip that prt?
Browser: Fine.  Here’s your page already.
Screenreader: <hum while fill out form>
Browser: Hmm.  The website says that city and zip code don’t match.  Probably a typo, but I should tell the user.  I’ll set the polite ARIA property.
Screenreader: Interesting.  I see the polite property has a message.  I’ll wait for a good time to tell the user.  <hum more>.  Perfect.  User, while you are between fields, can you check this?  Oh, it’s wrong?  I see.  Good, we get to fix our mistake.
Browser: That was nice and polite of you.

Conclusion
You came to hear  a funny speech.  You learned what ARIA – accessible rich internet applications are all about.  Without even feeling like you were learning.  My motivation for doing this was the Head First series of books which often teaches through humor, dialog and personification.  Remember ARIA may be rude or polite, but always helpful.  Just like Head First.

[edited to add sock puppet picture]