W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2015


From: Jesper Tverskov <jesper@tverskov.dk>
Date: Tue, 12 May 2015 10:30:32 +0200
Message-ID: <CAAuwN4Fuj8rC-7Ym40atLtN9wne0Q7OujupNBspHEn-BtMPR9w@mail.gmail.com>
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”,


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

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.

Jesper Tverskov

Received on Tuesday, 12 May 2015 08:36:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 May 2017 01:54:15 UTC