Day 21: ATAG Resources & WAI Vetting Process

I tend to do things backward, and my learning process seems to be no exception. Today I read through some of W3C’s Web Accessibility Initiative (WAI) informative resources and realized they’ve broken down ATAG documentation in a simplified way. And here I was going directly to the recommended specification and trying to break it down for myself. Well, I can’t say I didn’t challenge myself that way!

Things I accomplished

What I learned today

  • I’m learning something! My Part A and Part B posts, along with my study spreadsheet, all mirror what’s been written on the WAI website.
  • Learned the 5 milestones of WAI’s accessibility standard development process:
    1. working draft
    2. wide review working draft
    3. candidate recommendation
    4. proposed recommendation
    5. W3C recommendation (web standard)

ATAG Resources

W3C’s Web Accessibility Initiative (WAI) website has been recently overhauled this year and I’ve found a lot of great informational points on this site that have been easy to navigate. Some of their ATAG resources include:

Additionally, W3C has their recommended specification and implementation notes:

 

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 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 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 7: Learning VoiceOver on iOS

While I’m learning about how how some users perceive and operate pages, I think it’s a good time to start diving into some of the assistive technology (AT) that people use. A week ago I had a more cut and dry approach to the WAS Body of Knowledge, as seen on my Google calendar, but now I’m discovering a more natural overlap of ideas as my own curiosity grows and I attempt to apply these ideas in a useful and concrete way.

To start, I spent time with Apple’s VoiceOver (VO) on my iPhone. Why this particular AT first? Honestly, I needed it during work today to test and share with others. Secondly, it’s one I have the least familiarity with. It’s hard to go against how I normally use my iPhone! Yet, enough motivation and time has slowly brought me around and made me also think more on how this AT can lend itself to benefiting everyone in the screen-less world we are presumed to be heading into.

Things I accomplished

  • Successfully navigated my iPhone using VoiceOver without looking at the screen or giving up too easily out of frustration.
  • As part of my bi-weekly duties at work, wrote a short accessibility blurb meant to introduce librarians, archivists, and museum staff to VO on iPhone (not yet published at the time I’m writing this).

What I learned today

  • VO has a screen curtain mode that turns the screen off, while the functionality continues. This offers added privacy or could save battery power. Careful! I scared myself, not being able to toggle my screen back on. Fortunately, I’d practiced navigating beforehand and listened my way through Settings to turn VO off, which resolved the issue. Phew!
  • Practiced at least 5 ways to interact with my iPhone using VO:
    Gesture Desired Behavior
    Swipe down with 2 fingers Start reading continuously (from this point on)
    Tap with 2 fingers Stop reading
    Rotate both thumbs in sync (like a dial) Scroll through rotor for list settings and navigation options.
    Tap with 1 finger Select item
    Double-tap with 1 finger Choose item or activate button
  • I can comfortably listen to VO at a speed of 60%.

Food for thought

  • It seems to me the visually impaired have to sacrifice a bit more of their privacy just to accomplish what people, who don’t use screen readers, can accomplish on a daily basis (everything is read aloud).
  • Imagine if all of us practiced using VO. There could be benefits to not looking at your screen at every task, giving verbal commands for tasks, and gaining empathy and insight into how others interact differently with the same world.
  • I actually appreciated listening to, as opposed to looking at, some things. For instance:
    • small icons are often problematic for me to see, but VO suddenly brought clear definition to emojis and indicators that I may have only guessed at before,
    • I could listen to my email as I walked on my break, and still keep alert for what was around me, and
    • I could perform some tasks on my phone, without looking the screen lighting up the whole room, while my son drifted off to sleep tonight.

How you can learn to use VoiceOver on iOS

Day 2: WCAG Perceivable, Part 1

Day 2… a weekend day, which can make it harder to make time to set aside for studying. I did it, though, spending roughly an hour and a half working through documentation, mulling over only part of the first WCAG principle, and working toward visualizing the different guidelines, success criterion, and techniques. I didn’t get as far as I would’ve liked either, yet this is the deepest work I’ve ever done at combing through the WCAG docs.

Things I accomplished

  • Read through the PerceivableĀ principle in WCAG 2.1 documentation (normative and non-normative).
  • Started a spreadsheet to visualize relationships between principles, guidelines, success criterion, and techniques. Specifically I mapped out the perceivable principle.
  • DiscoveredĀ techniques that failed to meet criterion within the perceivable principle.
  • Dug into helpful solutions to common situations (satisfactory techniques) via W3C’s “How to Meet WCAG 2.1“. Seriously, this resource is extremely helpful for all those situations I’ve had to figure out how to be more inclusive, and the documentation is there to back up my decision when I have to present it to my team!

What I learned today

In the process of trying to memorize guidelines and success criterion, I reinforced the image of the layers that exist within WCAG:

Additionally, looking closer at each criterion helped me to identify the additions made to WCAG 2.0’s first principle:

  • Orientation
  • Identify input purposes
  • Identify purpose
  • Reflow
  • Non-text contrast
  • Text spacing
  • Content on hover or focus

When reading through the description about text alternatives, I ran across a concept new to me: “simpler language” is considered a text alternative under Guideline 1.1. Also, there are some identified exceptions to the text alternative guideline. Those exceptions apply to:

  • controls or input fields
  • time-based media
  • tests/exams
  • specific sensory experiences
  • CAPTCHA
  • decorative images or typography