- From: Jesper Tverskov <jesper@tverskov.dk>
- Date: Thu, 14 May 2015 11:20:11 +0200
- To: chaals@yandex-team.ru, w3c-wai-ig@w3.org
Let me elaborate on my original example, to make it all more clear. Let us say, I want to markup a multiple-choice test. For each question, I have the challenge of how to present the 5 answer options. Each option consists of a “a)”, a radio button, the answer option text, and because we have very many Chinese users, after the answer option text, we even have that text repeated in Chinese (the students are not too good in English), and because it is some advanced science subject, at the very end of each option we can even have an index number linking to a footnote with more information to the person sitting for the test. Now, my first solution would simply be to use the List element. The answer options are true list items, and using a list element (ul, li), makes it easy to present it all nicely with alternating background colors. Now, I am entering the scene. A true accessibility and usability freak of the fundamentalista type. I want my webpage to be extremely adaptable to any browser, any platform, low resolution, extremely narrow view port in the browser, extreme ZOOM higher than 200%, etc. For those reasons, I find it necessary to drop using LIST elements. I need a design table in order for all the information items in each option to align vertically in the middle if line break and word wrapping takes place. >From a visual user’s point of view, the above alignment concern (we want it to look as nice as possible in any situation), is the only reason to use a table, with each information item of each option in a cell of their own. The interesting thing is that for the sake of the argument, we could add proper headings for each column but we still have a table of design. But the design table very much also looks like a data table, and it has all the characteristica of a data table except that it is not of the conventional data table type, we are so used to. Now the big challenge. Should I use role=”presentation” for the above table of design? Or, is the user of screen readers much better off, if I pretend that it is a true data table? If we pretend that it is a data table, I believe it is much easier for users of screen readers to understand and navigate the answer options. It could be reported that we have 5 rows that is 5 options. It is much easier, after a while, to ignore the last column with the index number, or the Chinese translation column, if this user is very good in English, et cetera. So please ..., is it likely that I could help users of screen reader by pretending that my table of design is actually a true data table? Cheers Jesper
Received on Thursday, 14 May 2015 09:20:39 UTC