Accessibility and HTML: Accessibility for Everyone: Long Form Book Review

As seen in my last few entries, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

ACCESSIBILITY AND HTML

This is the payoff point. With solid, well-structured HTML, most of the struggle to make sites accessible becomes very simple. That's it! Oh, wait, you want to know what that actually means, don't you ;)? Well of course and that's the meat of this chapter.

Many of us learn the basic HTML tags and we think that's all we have to do. Not much to it, except for the fact that there are lots of parameters for nearly every tag, and understanding those parameters can help immensely in making sites more accessible. Turning off CSS in your browser can be very informative, as well as jarring. Pretty sites get reduced to a listing of text and spaces only and with it a much clearer idea of how your pages are actually structured and it also shows how a screen reader would walk through it. If you find yourself scrolling through a bunch of stuff to get to the main content, imagine how it will feel to a user utilizing a screen reader waiting for it to "get to the point already".

Being effective with headings can do a lot to help structure your page in a meaningful way. Think of an outline for a paper or presentation. You put certain elements at those levels for a reason, right? Make sure to use your heading tags the same way (h1 - h6, etc.). Lists are also helpful to break up the content and make it more readable, so use the proper list elements (ol, ul).

Forms are a prime location for people to add extra code to help make sure that the user is putting the right information in. The downside is that, for many using accessibility tools, these enhancements will be confusing at best and completely bypassed at worst. Also, while it's a common convention to put a red asterisk to mean that information is required, having a tag call out that it is required, or literally spelling it out is better.

For many users, the keyboard is not just the primary input tool, it is the only input tool. Therefore, it is wise to use conventions that are well known and understood. Be careful making your own conventions or overwriting long standard actions.

Skip links are found at the start of many documents. Since users may be familiar with the content they are after and know how to find it, presenting them with a navigation bar they have to address each time can be both training and time-consuming. Putting a skip link in means the user jumps over the navigation elements and gets right to the main content on the page.

Tab order is critical, so make sure that users can get to the content they need in as few steps as necessary by using the (tabindex) option.

It should be no surprise that HTML that is generated from WYSIWYG editors is often literal, overly verbose, and overloads each tag with meta details that are better put elsewhere, so paying attention to how your code is formatted is important. Additionally wherever possible, try to keep structural aspects in your HTML and move the style elements, wherever possible, to CSS.

Another important aspect to consider when writing HTML for accessibility is the notions of "Progressive Enhancement and Graceful Degradation". In a nutshell that means "start from a basic framework and add the aspects and elements that allow for the specialized tools while keeping the base experience similar for all users. Likewise, Graceful Degradation is the idea in the opposite direction. If something fails or doesn't apply due to a user's method of access, don't just shut them out. Instead, make it possible to view as much of the content as possible, even if some of it is unoptimized.

If' you've been around Accessibility any significant length of time, it's likely you have come in contact with WAI-ARIA tags. WAI-ARIA stands for Web Accessibility Initiative—Accessible Rich Internet Applications and is helpful in allowing for certain tasks to be described in a more effective way, beyond what HTML and CSS ever intended. If you have ever heard a screen reader counting down and declaring the percentage progress of a file being downloaded, odds are that behavior is being defined in an ARIA tag.

Each of these areas is described in more depth, but they are not comprehensive breakdowns of each. As I will mention again when I do my summary review, Laura is not writing a "what" or a "how" book as much as she is writing a "why" book. As the title states, this is "Accessibility for Everyone" and that goes beyond the role of the programmer trying to make the site. The nuts and bolts are important, but the philosophy is even more so.

KEY TAKEAWAY

Meaningful HTML is the key, and to make HTML meaningful, we need to understand what it's best suited for and when it's better to let something else (CSS, ARIA) step in and take care of things like styling and more advanced interaction. Structuring documents effectively and understanding how to place the most important information up front helps everyone, not just those in need of assistive technologies. Also, it's good for the soul to see what your site tells you without the eye candy present. If it's a mess and hard to distinguish what is what, that's exactly the experience users who need assistive technology will have.