Last year, I had an interesting conversation with my colleague Hans Hillen, who suggested using regular HTML heading elements within the data table's caption element. This technique is legal in HTML5, and ensures that not only is there an accessible name for the data table, but that screen reader users can also navigate using headings.
Author: Gez Lemon
In previous versions of HTML, it was invalid to have a heading element within the caption element. When a data table followed a regular heading, developers were reluctant to use the caption element because of the redundancy, yet using the caption element provides an accessible name for the table. Having an accessible name for the data table means that when a screen reader user navigates to a data table, they hear a title for the data table, rather than have to navigate through data cells to determine its purpose, or navigate to the previous heading element and hope that it's the correct heading for this data table.
As headings are now allowed in the caption element, providing the heading within the caption element ensures that not only can users benefit from heading navigation, the data tables also have an accessible name is announced when the user first navigates to the table. The name also appears in JAWS' table list using the keystroke: CONTROL + INSERT + T.
I like the idea as well and have recently started recommending it. Makes perfect sense combining two accessibility features into one. I recommend setting fieldset legends as headings also.
Posted by Paul Adam on
Having a heading element within the legend element isn't valid in HTML5, but I agree that it would be useful for situations where that would be beneficial. I must admit that it isn't often that I've encountered a form where it would be useful if the legend was also a heading, but there certainly are scenarios where it would be useful. It would be great if this was legal in HTM5, but from a pragmatic perspective, it works.
It's a balance between making sure the structure is semantically correct, and not overusing heading elements to the point they're no longer useful for users to navigate and orientate themselves within the content.
Posted by Gez on
Paul, I agree with Jez regarding fieldsets. In most cases, I do not find the need for fieldset content to be headings as well. Depending on the screen reader, there is likely to be additional verbiage when field labels are read. (I need to do additional testing to verify this assertion.) I have begun to encounter pages with too many headings. Long forms with multiple fieldsets may need headings--particularly if form sections aren't collapsed. this is a case where UX for screen readers trumps semantics.
Posted by Pratik Patel on
Hi Guys, yes it is not too often you'd need to wrap the fieldset legend's text with a heading. Probably never for a question with a group of radio buttons or checkboxes for answers. I'm mostly thinking about examples where you have groups of similar text inputs like Billing Address and Shipping Address.
I agree that we should not be overusing headings when not necessary. Mostly I see issues where people visually style text as headings but don't code it as a heading. I see that problem with table captions and sometimes with text that should be a fieldset legend.
Looks like your post has gotten a lot of traction on Twitter. It's great to explore new ideas in accessibility!
Posted by Paul Adam on