Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial
Latest comment: 14 years ago by Dodoïste in topic Unbulleted lists
Unbulleted lists
At the risk of increasing the number of templates in an article, there is a space-saving template called {{Unbulleted list}} which might be useful when tables become wide. It produces the correct semantic markup for a list, which is exactly what is needed when a data cell contains a lower hierarchy of data (in this case a list). Here's an example:
| Title | Album details | Peak chart positions | Sales | Certifications | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
| Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) | |
| Nevermind |
|
1 | 2 | 2 | 1 | 5 | 2 | 2 | 1 | 2 | 7 | 10 million(US) 26 million (worldwide) |
Diamond (US) 2× Platinum (UK) |
would become:
| Title | Album details | Peak chart positions | Sales | Certifications | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
| Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) | |
| Nevermind |
|
1 | 2 | 2 | 1 | 5 | 2 | 2 | 1 | 2 | 7 |
|
|
This also removes some of the the superfluous column widths (if you must have them, use ems because you don't know the metrics of the client's browser font) as well as the deprecated <br /> tags that are being used to visually mimic a list. Also, style="text-align:center" is much better than setting a td to the deprecated align=center. As usual, this isn't compulsory, but it is much better practice. The extra whitespace indenting in the unbulleted lists is only there to help make the structure clearer. I don't expect every editor to cope with this sort of markup, but there's no reason why experienced editors can't improve this as they clean-up tables. --RexxS (talk) 14:47, 10 September 2010 (UTC)
- I do agree about the widths. Widths do make the table look prettier. But they should be made of
emrather than pixels. A good practice that I forgot to apply here. Thanks for reporting. :-) - I agree about
style="text-align:center"as well. - Now I'm not sure about this particular use of unbuletted lists. Sure the principle is good and all. But I'm not sure it's worth the effort here. In the "Album details" column it saves a little space. And in "Sales" and "Certifications" column it can sometimes indicate a list of two items. It's a lot of code for a small change. However, The Prodigy discography contains a few examples where unbuletted lists would really be useful (lists of 4 to 7 items). It needs some more thoughts (and possibly feedback from users) on my opinion.
- I do agree about the widths. Widths do make the table look prettier. But they should be made of
- Among tables, there are some far more urgent use of {{Flatlist}} (with another layout) in {{Navbox}} for example. I'd rather work on a large-scale important improvement on Navbox than a few lists here and there. Priorities, priorites. ;-) Dodoïste (talk) 04:35, 11 September 2010 (UTC)
- At a second thought, the widths are set to create a cellpadding. And ems doesn't work in the width attribute. Maybe the % would be a good solution but I'm not sure. Is there a reason why
cellpadding="5"doesn't work withclass="wikitable"? Cellpadding would definitely be the simplest solution. - If cellpadding are used it also solves the issue with centered text as text becomes centered by default:
align=centerbecomes useless. Regards, Dodoïste (talk) 17:29, 12 September 2010 (UTC)
- At a second thought, the widths are set to create a cellpadding. And ems doesn't work in the width attribute. Maybe the % would be a good solution but I'm not sure. Is there a reason why
Avoiding more than two levels of headers
The table given as the good example could be improved by using row headers (in this case the distances). Remember, screen readers are capable of non-linear navigation, so the ability to announce the [column header][row header] before any cell value can be more effective when row headers are present, particularly on larger tables. --RexxS (talk) 15:05, 10 September 2010 (UTC)
- In theory I agree of course. In this particular case I was unsure the distance would made relevant row headers. But at a second thought – and after I saw more use cases – I think you are right. :-) Dodoïste (talk) 15:16, 10 September 2010 (UTC)
Images and color
Collapsible tables can also work without the faux header:
| Country | Purpose | J | F | M | A | M | J | J | A | S | O | N | D | J | F | M | A | M | J | J | A | S | O | N | D |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Australia | x | x | x | x | x | x | x | x | x | x | x | x | |||||||||||||
| Canada | x | x | x | x | x | x | x | x | x | x | x | x |
But some people may not find it as "pretty". --RexxS (talk) 16:27, 11 September 2010 (UTC)
- Interesting. So the script chooses the first header and add the "show/hide" button to it. It's a pity we can't choose the header on the far right. "Show/hide" buttons are always on the right. Usability-wise it would be better to have consistent types of contents. I wish the usability team would complete their Style Guide and ask users to comply to it. It's a good practice on Web projects. For example, we decide that link are blue and underlined on mouseover and onfocus. This behavior should never change on Wikipedia: it becomes a rule. It should be kind of similar with collapsible content: the appearance and behavior should never change.
- The best solution would be to improve the script. So that it adds the "show/hide" button to the caption instead. It's a lot of work as every table using this collapsible script should be fixed (and probably manually). Still, it's definitely something we will have to do sooner or later. I believe it would be better to gain experience with other simpler tasks. And afterwards we should make a task force for this job. Regards, Dodoïste (talk) 01:20, 12 September 2010 (UTC)
- If we could ensure every table had a caption, then it would be the perfect place for the show/hide trigger. One day, maybe ...
- Incidentally, my links are whatever colour I want, as anyone can override most global style choices in their own /[skin name here].css file. For example, I like to be able to pick out recently visited pages on my watchlist, but I'm somewhat colour-blind between the default blue link and the default for a visited link, so I set
a:visited { color: #8800C0; }
- Similarly, anyone can override default behaviour for classes, such as the class="external text" to change the style of external links only. Of course, all of this works as simply as that, only if we don't embed in-line styles in elements.
- You've made a lot of progress with giving good accessibility advice here, and all of it will also be useful for those working on the usability project – good accessibility and good usability have a habit of going together. Cheers --RexxS (talk) 04:06, 12 September 2010 (UTC)
- Yes, one can override most global choices in their own skin css file and it's a good thing. It's very important accessibility-wise. Users can select/add a style sheet directly in their browser and have it applied for all websites (or may even be able to have website-specific style sheets). The !important declaration is made especially for this purpose: it overrides the website's style sheet and inline styles.
- Still, the default appearance should not change. When users customize style sheets it's their responsibility and choice (and needs). The default appearance should be consistent nonetheless.
- "I'm somewhat colour-blind between the default blue link and the default for a visited link": as many of us average users. The usability team received a lot of complaints about it. But strangely - especially for a usability team - they did not take this feedback into account. WTF?
- Thanks. :-) I'm glad to be able to help. Yes, accessibility and usability projects should collaborate more. For example, the only solution to solve most of the contrast issue with colors in articles and templates is through usability. It's far too complicated for the average user to test color contrasts with the Color Contrast Analyzer and corresponding guidelines. It's easier to decide that "for usability reasons the colors used in Navbox should be ... (insert relevant choice here) and that rule should never change".
- Also, did you notice how I make the navigation in this Wikiproject? I used two usability recommendations that are almost never used on Wikipedia: a breadcrumb, links in the menu are organized in sub-menus that do not contain more than Seven plus or minus two items. How about we organize help pages like that? It would surely make it easier for newcomers. Regards, Dodoïste (talk) 16:01, 12 September 2010 (UTC)