- From: Jesper Tverskov <jesper@tverskov.dk>
- Date: Tue, 12 May 2015 10:30:32 +0200
- To: w3c-wai-ig@w3.org
Hi list A couple of weeks ago this list advised me to use role=”presentation” in HTML table markup used for design. This is probably good advice most of the time but I have the feeling that this is sometimes flat wrong. We should be aware of the fact that accessibility always comes first. We should not be formalistic, and do things to live up to accessibility guidelines, when not doing so makes a web page more accessible. My original problem or challenge, as expressed in my blog-like article, “When even nested HTML tables are just great”, http://www.friendlytest.com/doc/en.When_even_nested_HTML_tables_are_just_great.html, was to present the answer options for a multiple-choice question as accessible as possible. The ideal approach is to use the HTML list element. But it is difficult to control vertical alignment of the radio button and the text in each line if extreme zoom, low resolution or a narrow viewport in the browser window causes a line break and word wrapping. For that reason, I use table elements instead of list elements. I can then have an answer option in each row of the table, and each row could have two cells, one for the radio button and one for the text. This is a table used for design but the table also acts well as a data table in the following sense: In the first column, we have the radio buttons, and we could have had a header saying that. In the second column, we have the text part of the option, and we could have had a header saying that. Now the original argument for using a list element is that it is nice that a screen reader can report: “List with 5 options”, and even give some shortcuts to navigate them. When using a table for design without using role=”presentation”, a screen reader might report: “Table with 5 rows”, and even give some shortcuts to navigate them. After a while, the table becomes a signpost saying: “We have arrived at the answer options”. Very, very nice. If we use role=”presentation” the user of a screen reader gets nothing. Only the content is reported. Conclusion: Never user role=”presentation” for formalistic reasons. Always consider what serves the user best. In the case of tables used for design, the table could have a secondary function of giving better structure to a page making it easier to understand and navigate by a screen reader. This will typically be the case, if the table, after all, is also a data table, because we have solid relationships expressed in it. Since I would like to include some of the above in my blog-like article, I would like to hear, if you agree, that we should always do what is the most accessible, not just follow guidelines in a formalistic manner. Cheers Jesper Tverskov http://www.friendlytest.com
Received on Tuesday, 12 May 2015 08:36:12 UTC