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

Re: role="presentation"

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Tue, 12 May 2015 09:54:56 +0100
Message-ID: <CA+ri+VmbZHLvC7dVFC=zqdvZVmw8=UTGMCv+jug=Qe1m_yOjJA@mail.gmail.com>
To: Jesper Tverskov <jesper@tverskov.dk>
Cc: WAI Interest Group <w3c-wai-ig@w3.org>
Where you have a set of radio buttons, the set size information is already
provided via the accessibility API, when you want to group a set of
controls and provide a group label you can use fieldset/legend or ARIA to
acheive this.

You don't need either lists or tables to provide the information.



HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>

On 12 May 2015 at 09:30, Jesper Tverskov <jesper@tverskov.dk> wrote:

> 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:56:04 UTC

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