Day 20: ATAG, Part B

Today I moved onto the second major portion of the Authoring Tools Accessibility Guidelines (ATAG) spec to learn about how the content and code being produced by authoring tools should be accessible and how authors should be able to easily make that happen. It comes to no surprise that there are more references to WCAG principles and its conformance levels.

Things I accomplished

What I learned today

  • Part B has 4 principles, 11 guidelines, and 32 success criteria.
  • The second major part of ATAG is intended to encourage support of the production of accessible content by the author in that:
    1. all automatically generated web content should be accessible (conforming to WCAG 2.0),
    2. authoring tools need to help authors in produce accessible content (conforming to WCAG 2.0),
    3. accessibility checks and repair options should be available to the author which identify accessibility problems that don’t conform to WCAG 2.0, and
    4. accessibility features should be prominent and documented for ease of use by the author.

Day 19: ATAG, Part A

The Authoring Tool Accessibility Guidelines (ATAG) 2.0 have been fairly easy for me to read, so far. Having spent a significant amount of time studying WCAG, I’m noticing the similarities in principle, guidelines, and success criteria. All the more, it seems reasonable to expect web developers to assimilate ATAG into their mindset and workflow.

Things I accomplished

What I learned today

  • Part A has 4 principles, 13 guidelines, and 31 success criteria to follow.
  • If I’m using WCAG as a guide in all things web development, then following Part A of ATAG shouldn’t prove much harder. (“POU” out of “POUR” is literally present) More proof that digital accessibility is a mindset and not a checklist.
  • SC A.2.2.1 (Status Indicators) really opened my eyes to just how many visual indicators I have when creating a blog post! For instance, a red dotted underline to indicate a typo, a “Saved” text status in gray, or a number in a bubble next to my blog’s name to indicate that a draft is awaiting publication. So many things that could be missed if not made perceivable to assistive technology, like a screen reader.

Random share

Accessibility Pro Certified: To Be or Not To Be (24 Accessibility) is a timely article by Glenda Sims that answers the questions of “what is an accessibility professional?” and “how do I become one?” Perfect timing for me, as I’ve been wrestling with these questions myself, which pushed me to create this site and challenge. I could’ve used this insight a year ago when I did my first 100 Days of A11y challenge, which involved a more loose direction than I have now.

Day 18: Introduction to ATAG

ATAG stands for Authoring Tool Accessibility Guidelines. Thanks to my pursuit to study for the WAS certification exam, this was my first introduction to ATAG. Sadly, I wish I’d been exposed to this earlier. This is an important specification recommended by W3C to offer guidelines in making web authoring tools (like WordPress) accessible to content creators (e.g. bloggers) who may have a disability Secondly, ATAG offers guidelines for developers, so that the code produced by their authoring tool of choice (e.g. WordPress) will output accessible code in order to make an accessible website (WCAG comes into play again).

For me, reading this spec for the first time, this is timely. I’m starting to see so many State of Alaska departments leaning on content management systems (CMS) to generate and update their web presence. My concern has grown about how accessible these sites are (is semantic code outputted?), but I’ve had nothing solid to back up my concern. Fortunately, others are way ahead of me and have given their time to form a specification to support this very concern.

This spec holds even more relevance for me as I continue to produce content for this site via WordPress.

Things I accomplished

What I learned today

There are two major parts of the ATAG spec:

  1. accessibility of authoring tool user interfaces to authors with disabilities, and
  2. support by authoring tools for the creation, by any author (not just those with disabilities), of web content that is more accessible to end users with disabilities.

ATAG shares similar guideline traits as WCAG. Each major part has principles, guidelines, success criteria, and three conformance levels (A, AA, AAA). This structure should help me absorb its documentation much easier than ARIA!

The definition of “authoring tools” in the ATAG glossary lists of several avenues that I didn’t even consider at first sight. Those tools include:

  • WSYWIG HTML editors (Dreamweaver, TinyMCE)
  • software for editing source code (VS Code)
  • software that converts to HTML (“Save As HTML” in Office docs)
  • IDEs (Visual Studio)
  • software that generates web content on the basis of templates, scripts, command-line input or “wizard”-type processes
  • software that quickly updates portions of websites (Wikipedia)
  • content management systems (Drupal, WordPress)
  • email clients that use rich HTML (MS Outlook)
  • multimedia authoring tools (iMovie)
  • software for creating mobile apps

Extra reads


Day 17: ARIA Authoring Practices

Today I quickly went through the ARIA Authoring Practices 1.1, a W3C Working Group Note included in the ARIA suite of documentation. Though I found the WAI-ARIA 1.1 spec a bit hard to retain, this additional “note” helped me see some real-life application of the ARIA spec. It’s definitely something I’d recommend web developers bookmark when needing to refer to common pattern examples, use of landmark regions, and a how-to for developing a keyboard interface. It’s an informative resource best tapped into for specific information, rather than a document read from top to bottom.

Things I accomplished

What I learned today

There are a couple principles behind why using ARIA can be a challenge, and why sometimes it is better to not use ARIA rather than write bad ARIA:

  1. A role is a promise, so you better couple expected keyboard functionality with that role
  2. ARIA can both cloak and enhance, so use this power cautiously

This guide does not provide help on mobile and touch support. Apparently, ARIA is not consistently supported in mobile browsers. On that note, if you notice my resource mentioned at the end of this post, ARIA isn’t consistently supported across screen readers (it’s only 70% reliable!), and varies even more depending on the browser the screen reader is paired with.

Concerning role=”presentation”, this role is ignored, if one of the following is true:

  • the element it is applied to is focusable (links or inputs)
  • the element it is applied to contains any of the 21 global states and properties.

Must-read resource

Day 16: ARIA States and Properties, Part 2

Today I went over more ARIA States and Properties. Honestly, I’m still feeling a bit overwhelmed trying to learn all these, but I’m not going to get too stuck on memorization at this point. I’ll find ways in my future studies to come back to these when I’m actually applying them, where necessary when HTML gaps are present.

Things I accomplished

  • Noted all the states and properties in my Google spreadsheet, trying to get a better handle on what they are, how they are related, and which are not native to HTML5.

What I learned today

  • 22 out of the 48 attributes are not currently native to HTML5 (according to the Using ARIA draft documentation).
  • In my Part 1 post, I didn’t account for duplicates across categories. Instead of there being 67 attributes, there are 48.

I still have so much to learn…

Cool finds

Day 15: ARIA States and Properties, Part 1

Though there is still much for me to learn about ARIA roles, I’ve moved onto States and Properties of ARIA. ARIA is definitely challenging my ability to stay above water when it comes to information overload. Only 1 hour spent wading through information today.

Things I accomplished

  • Read through part of the States and Properties section.

What I learned today

  • States and properties are “aria-” prefixed attributes describing the object.
  • A key difference between the two: state values change frequently, unlike most property values.
  • There are 21 global states and properties, meaning they are supported by all roles and base markup elements.
  • Additionally, 46 more states and properties are broken down into four categories:
    1. widget: receives user input and process user actions; 24 attributes
    2. live region: updates content without user focus; 4 attributes
    3. drag-and-drop: identifies draggable elements and drop targets; 2 attributes
    4. relationship: clarifies associations between elements; 16 attributes

Cool finds

Day 14: ARIA Roles Model, Part 2

Two weeks of consistent web accessibility studying down! And a total of 24 hours (non-consecutively) spent.

Today I continued on reading through The Roles Model, this time diving deeper into the definitions of each role. 82 roles is a lot. At times I shifted over to informational documentation to get a well-rounded grasp of the use of ARIA, rather than spending a full hour reading straight through the role definitions.

As an added note, learning (memorizing) these roles could take days, if not weeks. In order to stay on my study schedule, I think reinforcing this type of knowledge is best suited in practice. When I begin studying and creating custom interactive controls and widgets (per the WAS Body of Knowledge), I’ll circle back around to ARIA roles.

Things I accomplished

  1. Added the Rules of ARIA to my spreadsheet.
  2. Read through a few of the role definitions (and accompanying documentation) to get a better grasp of their differences and purpose. The alphabetical list works best for quick research, but I chose to systematically look at roles by type to more easily assimilate them into my own knowledge base. I also focused more on roles that currently do not have an HTML equivalent.

What I learned today

  • Role=”directory” is for static table of contents. I could definitely be using this alongside my aria-label=”Table of Contents”. Up to now, I’ve just been using the HTML navigation landmark.
  • Role=”alert” shouldn’t be coupled with focus (like a close alert option), but role=”alertdialog” does. Key difference. That, and “alert” is a live region role, while “alertdialog” is window role. Understanding the role types first is key to helping understand the what and when to use of these roles.
  • ARIA only validates on checkers when used in an HTML5 doctype.
  • There is a hack for giving alternative text to background images. Not surprising since ARIA feels like a hack anyhow. I’m not going to give the code here, as I think it’s just too much of a work around for devs. Just use the HTML img element, please.
  • 31 out of the 82 roles are actually the most relevant. Others have HTML5 equivalents (remember the first rule of ARIA?) or are abstract. These seem like the best place to start when learning ARIA, cuts down memorization, and could prevent potential barriers presented to assistive technologies.
    🎵 “You may say I’m a dreamer, but I’m not the only one…” 🎵 (John Lennon)

Food for thought

After all these years the Internet has been alive, why don’t we have an HTML search landmark??

Helpful resource


Day 13: ARIA Roles Model, Part 1

The WAI-ARIA specification is a doozy! Today I waded into The Roles Model, after feeling a bit lost in some of the earlier parts of the spec. I was feeling pretty run down by the end of my day, so I only spent half an hour on this spec, mostly trying to get my bearings.

Things I accomplished

What I learned today

I didn’t realize just how many roles there were in ARIA! Spoiler: there are 82, if you count the abstract roles. Each role falls into a category:

  1. Abstract (don’t use these)
  2. Widget
  3. Document structure
  4. Landmark
  5. Live region
  6. Window

Abstract roles were new to me. Rightly so, since they are not supposed to be used in my code.

Document structure role=”none”?? That one I’ll have to research further. It sounds vaguely familiar from the Internet somewhere.

Out of all of these role types, I am the most familiar with landmark roles, even though I rarely use them, since I lean more on HTML5 landmarks.

Day 12: WCAG Reinforcements and ARIA Conformance

Time spent pursuing web accessibility knowledge: 2 hours.

Things I accomplished

  1. Watched a Deque webinar about WCAG compliance and measuring digital accessibility success. (I see another blog post in my future…)
  2. Submitted a support request to a vendor my work subscribes from, written with the intent of what a web accessibility specialist may recommend (identify the problem, point to references, and offer a tangible solution)
  3. Read ARIA’s conformance text.

What I learned today

I got so much out of Glenda Sims’ “Accessibility and Compliance” webinar! So many things to think about when evaluating how we measure the success of digital accessibility (what yard stick to use), the levels of goals to achieve, and evaluating our own intentions. This will be a future blog post, for sure, as well as a brief presentation at my next in-house accessibility meeting.

Part of the ARIA spec I read today was a little less inspiring. However, it did make me do a double-take on what parts of the spec are normative and non-normative. That’s something I grasped quickly in the WCAG spec, but not as quickly in the ARIA spec. I’ll need to look closer at this documentation to be sure I understand it enough to check off that bullet point of the WAS Body of Knowledge. So, in short, I learned that I don’t always know what I think I know. Not a new lesson, right?

Resource new to me

  • Poet Training Tool: learn when and how to write alternative text for images; practice writing alternative text

Day 11: Diving into ARIA

I’ve finished studying WCAG! Now onto ARIA, the next item in the checklist from the WAS Body of Knowledge. WCAG’s Robust principle seques into this. As SC 4.1.2 states:

“For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.”

The WAI-ARIA specification says that it exists to provide:

“an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications.”

And so the twain shall meet when development of custom components occurs.

Things I accomplished

I got a slower start on these docs, as I just wasn’t as familiar with them. WCAG had a straightforward POUR outline. ARIA docs didn’t have as easy an access point for me, so I had to spend some time trying to create an approachable framework for myself to navigate the less familiar territory. I did manage to:

What I learned today

So many things!

Always Remember

“WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement.” -and- “It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object.”

It’s tempting to use ARIA, since it’s a bit more mysterious and, therefore, appealing to master, but it can’t be stated enough: don’t use ARIA if you don’t have to. I’ve heard this before, seen it stated in different documentation, and completely agree. Use semantic HTML first.