Re: role="presentation"

Steve is right except that it does not solve my problem:

How to make the radio button align vertically in the middle when
extreme zoom, low resolution or a narrow view-port in the browser
window tilts the answer options of the multiple choice test, creating
linebreaks, word wrapping.

Jesper

On Tue, May 12, 2015 at 10:54 AM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> 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
>
> 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 11:41:31 UTC