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