Day 87: Guidelines, Laws, and Myths

My intention today was to complete the first Deque course within the WAS certification prep program. I did do that, but not without being led to more resources that I need to read through. I’ve done a little research into US laws, but I need to read them again, plus read other laws mentioned in what I reviewed today. Looks like tomorrow’s study session is laid out for me.

Thing I accomplished

Completed guidelines, laws, and myths sections of Deque’s Accessibility Fundamentals.

What I reviewed today

Guidelines

Principles, guidelines, and authoring practices help create an accessible interaction between user and website or application. These guidelines and practices ensure that a variety of disabilities are taken into consideration.

I covered these more in detail on my own, which I’ve journalled on this site, but Deque does a decent job of getting the learner started with the basic principles and guidelines, and points them to official specifications. I’ll admit, I need to go back and spend some serious review time to go over all these.

Laws

Web accessibility laws usually fit into one of the following categories:

  • civil rights: discrimination against disabilities (Americans with Disabilities Act)
  • procurement: purchasing accessible IT products (Section 508 of the Rehabilitation Act)
  • industry-specific: regulations for private industries (21st Century Communications and Video Accessibility Act, Air Carrier Access Act)

United States

Canada

Europe

Other Regions

The Web Accessibility Initiative (WAI) has a comprehensive list of international accessibility policies. Additionally, PowerMapper has a list of government accessibility standards.

Myths and Misconceptions about Accessibility

  1. It benefits only a small minority. Truth: It actually benefits everyone.
  2. It’s a short-term project. Truth: It’s on-going.
  3. It should be the last step. Truth: It needs to start at the beginning of the project and last throughout the project’s life cycle.
  4. It’s hard & expensive. Truth: Remediation is harder and more expensive than considering it throughout the life cycle.
  5. It’s ugly. Truth: Most accessibility features are not visible to everyone.

Best takeaway

“Inaccessible web sites are not just inconvenient for people with disabilities, they are blocking.”

Day 22: Implementing ATAG

Despite what my study calendar says, today was my last day spent fully focusing on the Authoring Tools Accessibility Guidelines (ATAG). I’ll be spending the weekend experimenting with a couple assistive technologies (AT), learning and practicing some accessible code, and reviewing some of my notes for standards I’ve learned. ATAG has been fairly easy to understand, and will likely be even easier to implement once I have a chance to put it to practice this winter.

Thing I accomplished

What I learned today

There is no way I’ll remember all that I read today or even be able to sum up the wealth of information offered, but I rely on the fact that there is additional technical information to aid in meeting the success criteria of ATAG via Implementing ATAG 2.0. This parallel documentation (notes) adds intent, examples, and related resources to help a developer make better accessibility choices.

Resource unrelated to ATAG

I’ve been really impressed with many of the articles on 24 Accessibility that have been published this month. If you haven’t had a chance to read any of those articles, do it! So much good information covering a variety of topics within web accessibility. You’re missing out if you haven’t tapped into the expertise that’s been made available all throughout the month of December.

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 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