- From: Jesper Tverskov <jesper@tverskov.dk>
- Date: Tue, 12 May 2015 13:41:03 +0200
- To: w3c-wai-ig@w3.org
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