Re: role="presentation" [SEC=UNOFFICIAL]

Thanks Leon for taking your time to tell me about the CSS display
property and the table related values. But I know about this method,
which I consider a no go.

I asked about that method at this list, a month ago under the subject
line: "CSS display property and tables".

I my opinion this method should not be a last resort to avoid the very
last table of design, as I explain in my article, "When even nested
tables are just great",

http://www.friendlytest.com/doc/en.When_even_nested_HTML_tables_are_just_great.html

In the thread I asked, if the Accessibility Community agrees with me:
The table related values of the CSS display property is people's own
business. It is not a proper approach to be recommended by the
accessibility community to solve accessibility issues.

Only Chaals gave a clear answer.

Cheers
Jesper

On Wed, May 13, 2015 at 1:57 AM, ANDERSEN, Leon
<Leon.ANDERSEN@dss.gov.au> wrote:
> Hi Jesper,
>
> In my opinion radio buttons are not data and what you are using the table for here is layout.  I think trying to blur the line between what is a layout table & a data table to justify an approach is a slippery slope. How long until we justify using a data table for a 3 column page layout of navigation + content + aside by giving them table headers of navigation, content etc...
>
> Here's a solution to your initial layout issue. By (ironically) using css display:table & table-cell you can achieve the desired alignment  of the radio button and the nice wrapping of the text/label. Not supported in IE 7 and below though.
>
> And unfortunately a <span> is needed to wrap the radio to allow for vertical alignment.
>
>   <ul>
>     <li style="display:table; ">
>        <span style="display:table-cell;vertical-align:middle;">
>           <input type="radio" id="radio" name="radio">
>        </span>
>        <label for="radio" style="display:table-cell">I am a radio button I am a radio button I am a radio button I am a radio button I am a radio button I am a radio button</label>
>      </li>
>   </ul>
>
>
>
> Leon
>
> -----Original Message-----
> From: jesper.tverskov@gmail.com [mailto:jesper.tverskov@gmail.com] On Behalf Of Jesper Tverskov
> Sent: Tuesday, 12 May 2015 6:31 PM
> To: w3c-wai-ig@w3.org
> Subject: role="presentation"
>
> 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 Wednesday, 13 May 2015 09:27:55 UTC