Re: role="presentation"

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.

--

Regards

SteveF
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
>
>