Archive for January, 2009

My Accessibility Check: Let’s All Use Our Headings!

January 30, 2009


Cringing all the time, I am cleaning up my web sites and these blog pages to conform to accessibility standards and my own growing experience with usability. I plan to break down this effort into HTML facets prioritized by the trouble I have using these features as I browse and perform transactions: headings, links, forms, navigation, graphics, etc.


Sighted readers of this post should learn more about the importance of headings to guide low vision and blind readers. New Vision Losers may learn some benefits of and tricks for using a screen reader. Listen to an excellent video on the importance of headings.

The Values of Standards

For this exercise, I will be using the WebAIM simplified WCAG checklist. . The w3 standards are certainly thorough, technically rooted, and well stated. But each facet of web use is complex in its own way with technical lingo related to not only browsers and HTML but also human psychology and usability studies. Even richer are the problems of maintaining and using the ecosystem of trillions of web pages created in only 15 years by several generations of web developers using constantly changing web technology. Anyone approaching a standards activity is faced with numerous trade-offs, in social as well as technical values. So any checklist like this appears neutral about the relative importance of each criterion, leaving it up to accessibility statements to identify their values and responses.

If one were to assess values, questions would include: how much harm would be done by violation of a certain criterion? how many users would be harmed and to what degree? My accessibility checking process is based on my personal difficulties, with occasional harm to me but more often to the web page purveyor if I give up or move away in disgust. I have gradually zoomed in on Headings as a key criterion for usability of a web page design intent and execution, regarding the content and use cases for the web site.

Headings 101

Since the big inning of HTML time, an ea on ago around 1993, came the simple system: H1, H2, H3, H4, H5, H6. Browsers agreed to display these in different font sizes. Headings were a direct take-off on the section structure everyone learns in creating documents:, like chapter, section, subsection, etc. These looked really great in early browsers and conveyed the transferable semantics of sections and subsections, especially when heading wording was carefully crafted so that the headings alone conveyed a good outline of the page.

Then came page styles, with more concern for fonts, colors, and page layout. Standard heading styles didn’t always mesh well with desired look as pages were divided into frames, columns, and navigation bars. So headings became more problematic and lost use. Search engines have been said to apply extra weight to heading terms on the assumption these were chosen to emphasize a section’s purpose and content. But super powerful indexing of terms on a page lessened the impact of headings.

Now, what do the standards say? Right up front, in 1.3.1 calls for semantics on web pages, not only headings but also proper tagging for lists, quotes, and real tables of data. “Semantics” means “meaning”, i.e. a heading covers a block of the page and lower level headings are lower in those sections. Following this logical argument, a page has a subject at level H1, sections that correspond to both content and use of the page. Here come some tricky parts if headings are used faithfully, e.g. what is the level of a search box, or page maintenance information, or, for that matter, the main content of the page?

The Webaxe podcast and blog on accessibility is an excellent tutorial and reference to other webs sources on accessibility. Here is WCAG 2.0 Guidelines for section headings

Rationale for using headings

Usability for screen readers

A screen reader strips out the visual only aspects of web pages and reads out the primary content: headings, lists, tables, graphic descriptions, links, etc. as well as paragraphs. My NVDA screen reader has explicit settings as to which HTML elements to read out as well as settings for the voice, e.g. amount of punctuation and indication of capitalization.


The first thing I do using Firefox and NVDA screen reader reaching a new web page is hit the h key to tour the page by headings, listening to both the descriptions and the levels, trying to build a mental map of the page. I can also use the 1,2,… keys to traverse the page by level of headings.

You tube video demo and appeal for using headings tells the story exceptionally well. With headings on a page, you are off and running into the content immediately. Without headings, I try looking for meaningful links, then lists, tables. Failing along the way, I grow increasingly grumpy if the page is long and must be covered line by line or by tabbing among HTML elements in the top-bottom, left-right reading order.

General readability and write ability

Just as I am never really satisfied with my own heading structure, I react to the intuitive flow of reasoning I discover in a page’s outline. The screen reader has a marvelous way of building or destroying confidence in the underlying design of the page and content. I can “feel” the flow of a page and the thinking of its authors.

With headings, I can drill down into the subjects that interest me, traverse backward and forward in skimming fashion, and maintain an understanding of the page’s content and my location within it. No headings and I must read linearly or traverse lower level elements, which often is appropriate for list elements but not strings of graphics or paragraphs.

Quality control and maintenance

Software engineers gradually learn the value of design, following templates, working top down, modularizing content, and many other principles. We learn that lack of structure will kill us when we need to make changes, which will happen sooner or later. We also understand a process called re factoring that systematically moves functions, expands classes, and regularizes parts of a system. It’s only a belief on my part, but I wonder if a page developer not using headings really knows what the page should be saying. Of course, real life suggests that the original developer is often long gone and the page owners are maintain the page themselves as their situations change. No wonder pages turn out so messy!

Another reason I react to poor heading structure is that I know the page has not been adequately tested with a screen reader and an at tentative human. If the only headings on a page are H5 and H1 that’s better the nothing, but why would the tester not recognize and fix this anomaly? Often this signifies that the page developers are following standards without real understanding or care. Another reason is the industrial origins of screen readers with $1000 price tags and adverse licensing that makes it difficult to test a page. NVDA obviates that reason, but there are still difficulties with the tester’s ability to understand a synthetic voice and work screenless.

Examples of headings

Here are some pages I like and dislike for their use of headings. Other visually impaired readers most likely will have other feelings based on their skills, tools, interest in the web site and content, and mental state.

Good use of headings

  1. W3.org web standards parent makes the tradeoff of using mostly level H2 sections with many additional pages in this large site. More subheadings could be used, it seems to me, for example in the months for presentations on the talks page.
  2. WordPress.com>/a> maintains excellent structure in its templates and working pages, such as tags. However, the main page jumps around from H1 to H6, obviously in search of some look I cannot appreciate via screen reader.
  3. google search results are organized by H2 for sponsored and search results with the results in a list at H3 level. Since headings are also links, this makes browsing a list of links quite rapid. However, in a stroke of inconsistency, news results and some other types of searches are not so tagged with headings., making the results far less useful with a screen reader.

Poor use of headings

  1. Word Web Online has only an H1 and would benefit from subsections for parts of speech, e.g. immediately calling a noun usage and telling other uses. Also sections for other dictionaries and linguistic tools would help.
  2. Association for Computing Machinery acm.org is the premiere computing professional association, that I unfortunately belong to for access to its digital library of publications. The heading structure is H1, H5, H5, H5, H1. What were they thinking? The page is not so badly organized but the heading read out is jarring.
  3. Computing Research Association has no headings or semantic cues. The page is laid out in visual sections but without any of that information transmitted via screen reader.

Exceptions from using standard headings

  1. While main Amazon.com is a royal mess with a page full of links difficult to classify by headings, alternative mobile accessible amazon.com/access has no headings at all. I find this acceptable in the spirit of minimalism that can be traversed in a few tabs or immediately to the product search box.

How did we stray from the wisdom of headings?

One reason for haphazard use of headings is certainly the conflict of the visual appearance of headings with desired look of pages, although this can be cured by style sheets. It is also difficult to reconcile section headings with navigation elements and actions from use cases on the same page as descriptive content. However, my bet is that a little more thinking could come up with palatable heading descriptions that would satisfy a screen reader user as well as a visual user. Additional arguments based on engineering principles for quality and maintenance are difficult to teach within software engineering but gradually become the stuff of bitter experience for truly professional web developers.

So, what do I advise?

  1. Use as many headings on your pages as you have logical groups of elements. If This one step is the most accessible step you can make for the broadest range of users.
  2. Try but don’t fuss too much over the true hierarchy, i.e. an H4 under an H2 or H2 topics not really at the same level. Using a screen reader will be much easier although the anomalies will be noticeable. However, each anomaly is something to question about your overall page structure.
  3. Of course, there are really no-win situations. An example is the use of headings within a blog post that don’t fit into the levels of a posting list as in wordpress tag surfer.
  4. Test your page using NVDA or a proprietary screen reader listening carefully to the sections and page outline. This is easy. Just start NVDA, set the preferences to the page elements you want, bring up Firefox with your page and type the h key around your headings. Other browsers may perform differently and you might need a more soothing synthetic voice but this should be part of any test environment.

Obama whitehouse.gov accessibility almost on target

January 21, 2009

I could not resist testing the new Obama whitehouse.gov for my pet peeves and latent hopes.

It was great to find an Obama administration agenda for disabilities. And right there on the home page were the RSS feeds for my enthusiastic subscription.

However, I immediately hit a few accessibility snags that suggest a bit more analysis and alterations would get the techno-government off to a better start.

Overall I like the page layout with site map in the footer, a design goal described in the whitehouse.gov accessibility statement.
My current pet peeve, subject of my own web site improvements and a future blog posting, is the logical page structure presented in well described section headings and a clear page outline. I quickly became confused as I toured the home page using my heading key and hearing the headings and their level. The w3 semantic data extractor profile tells
the story in its own outline of the page’s HTML.

Now any accessibility complaint has several components: the page itself, tools used by the user (NVDA screen reader, for me), the user’s skills (improving), and the user’s mental state and surroundings for perception and processing the page content. I’m confident there is an implementation problem here, although other visually impaired users might not find any difficulty or diagnose differently.

Ok, so I head off to the Contact page, and, whoops, a few more problems. Sigh, my immediate reaction to any form is a sense of impending doom as something always goes wrong and uses up a good part of my day’s energy. First, I could not figure out the actual required fields, so I had to fill all. I was not hearing any label read for each form field so had to tab around to find the field name. Missed the zip code and got an error message after submission. The comment box had a 500 character limit, with notice below the box so I exceeded my quota using the above web link. And I was unsure exactly which item was the submit button, actually labeled “contact us”. Now, this only took a few minutes and was typical of form-filling torture — I survived. Then I made another round to complain, sorry comment, about the form itself.

What is going on here? Is this web site a success or failure for one, picky partially sighted citizen? Overall, I’m pleased at the effort and general concept but disappointed that disability feedback did not fix the flaws that muddled my Inauguration after glow. My constructive suggestions are:

  1. Untangle and reconstruct the heading structure. A screen reader has an uncanny ability to reveal presence or absence of underlying logical thinking about page parts and their functions and relative importance. That’s the “semantics” in the w3 validator. In the long run, this quality of thinking about page organization will also pay off in maintenance as the web site grows.
  2. Rework the contact form. It’s doable but should be model of ease and functionality if the government is moving toward increased use of online forms for transactions, information, and oversight. And, by the way, why do I need to supply my zip code to make a comment?

Updates on whitehouse.gov accessibility

January 28 2009 Observations

  1. I am still befuddled by the Heading outline of the main page. It jumps around phrases like “Peril” to “search” and “blog” . I just cannot envision the underlying logic of the page although I can understand each of the parts when I get there. On the Disabilities page, the heading order read by my screen reader is H3, H2,H4 so I’m a bit confused at levels within the agenda.
  2. Last week I skipped over some mystery 1, 2, 3, 4 reading. This time I poked around more and discovered these bring up a short description of a feature above the boxes. But this dynamic content is not notified to my screen reader. Similar patterns of web design using this tricky interaction of web page with browser read by screen reader could cause great confusion if the content is really important. Right now, the numbers and features are just a bit of glitch in the way of accessibility.
  3. I subscribed to blog feeds on my Levelstar Icon PDA but nothing has come through. I need to check whether this is a non-standard feed that is not added properly to my RSS client.
  4. Just guessing when revisiting the comment page, that required fields are marked by asterisk. But I have punctuation speaking turned off in the screen reader so miss such a notification. As observed in another critique, the form lacks labels where the word Required or Optional might be spoken. This is pretty rudimentary accessibility practice covered in standards. Shame!
  5. The w3 Semantic Data Extractor link above produces the error message:

    Using org.apache.xerces.parsers.SAXParser
    Exception net.sf.saxon.trans.DynamicError: org.xml.sax.SAXParseException: The entity name must immediately follow the ‘&’ in the entity reference.
    org.xml.sax.SAXParseException: The entity name must immediately follow the ‘&’ in the entity
    reference.

    This might be a minor syntax error on the whitehouse.gov home page or a flaw in the validator. More later on whether other validators work. Also see the very interesting comment comparing whitehouse.gov with the British PM website.

Update Feb. 14 2009

More feedback from a partially sighted pro-Obama citizen using Mozilla Firefox 3 and NVDA screen reader. Let’s make sure only the best web techniques trickle down from whitehouse.gov to the rest of *.gov.

  1. Good!! The comment form fields now have labels and read like “First Name Edit”. However, I didn’t hear any label for zip code. And I still don’t know which fields are required.
  2. The 1-2-3-4 boxes for new features displayed in dynamic updates still did not provide any audible notice of change, just a different blurb of text I could see changing on the screen.
  3. I clicked “watch the movie” for the First Lady talk on “Do the right thing. Either the movie widget is invisible to me by either or seeing or the link failed. A good practice is to always tell the user if a plug-in or external app will launch, if in a new window, or other actions. I do know what’s going on here, sigh.
  4. Link description is drifting into the poor practice “Read this post”, “Read this post”, “Read this post”, … Why not merge this link with the post title?
  5. Headings? Schmedings!
  6. Overall, I still like the page layout and spaarceness of front page content with links to blogs and agenda issues for more details.
  7. Hey, let’s all import that Aussie free open source screen reader NVDA, buy a little TTS (text-to-speech) voice choir, and listen to our web sites for accessibility, usability, and friendliness.

Other reactions?