Talk:Accessibility/Table example

As noted in the main article, Wikipedia is already quite accessible. The three biggest problems I see are alternate text for images (which is to be expected given the terrible understandability of that attribute), misuse of semantic markup (e.g. '' is converted not to the agnostic <i>, but to <em> even when <cite> or <var> were meant instead), and an inconsistency in the presentation of article-specific navigation (e.g. previous/next elements, presidents, Olympics).

Wikipedia's use of tables is not a big problem, though I find its lack of support for <thead> and <tbody> annoying. Specifically, I see the following problems in the Wikipedia:Hydrogen table:

• The table is really a "Facts and figures" section, so like the other sections, it should have its own heading in text-only renderings -- though this isn't needed in the visual rendering where the layout makes it clear what the table is doing. ==[[Image:H-TableImage.png|Facts and figures]]== is somewhat cheeky, but works beautifully: any meaning from the image was too complicated/trivial to inflict upon text-only readers, so we're free to set its alternate text to a heading -- which visual readers don't need -- for the entire table. The same approach can be used in any other article where a facts and figures table begins with an image.
• Cell background color is being used to express meaning (the type of element), but this meaning is not expressed to non-visual readers. (There are similar practices in the articles on species and on astronomical bodies.) This is a similar issue to that of alternate text -- it might be okay to express some meaning only in visual media, if expressing it in non-visual media would be more annoying/time-wasting than useful for users of those media. But it's still brittle for article editors to be specifying the bgcolor each time -- better would be for articles on chemical elements to import a chemical-element.css style sheet, containing appropriate formatting for table.non-metal th, table.non-metal:after, and so on.
• The table subsections aren't using subheadings. (This is fixed in the example revision.)
• All the cells in the first column are header cells, so they should be <th>s, not <td>s. (This might improve the Lynx rendering, I'm not sure.)
• Multiple data are squashed into a single row just because they happen to be short (e.g. "Group, Period, Block"). This is hard enough to understand in a visual rendering, let alone any other kind!
• Though the headings and values are in different cells, the headings should still probably end in colons. Wikipedia's tables suffer from ugliness more than inaccessibility, but the excess of borders also hides the accessibility problem that the cells are running together in browsers that don't lay out tables. I think converting the table to a bunch of lists is overdoing it a bit; this data is semantically a <table>, as you can see by adapting the table to compare two elements (the second element would be just another column).

The right-alignment in Lynx is a bug in Lynx. It's interpreting <table ... align="right"> to mean that the text should be aligned right, rather than the table as a whole, and that's just wrong. This could and should be worked around, however, by using CSS instead of presentational HTML to float the table to the right.

Feel free to cut and paste bits of this comment to pages where they better belong.

-- Mpt 15:54 30 Jun 2003 (UTC)

To me it seems overkill to use a table for something that a list works perfectly well for. It doesn't even have to be a list; a definition list may be better, actually. In table form, it's many rows with essentially only one column of data (as you say, if we adapted it to compare two elements, but we aren't doing that, as far as I know). If we were using it for many different columns of data, a table makes more sense to me, but a list of some kind (whether it's UL or DL or whatever) is much simpler and considerably easier to edit.

Anyhow, tables are obviously a big sticking point, since there are so many different (often inappropriate) uses for them. I'm not at all opposed to their use, but where a simpler solution works just about as well, the simpler solution seems better to me. In this example, the list is easier to edit, somewhat easier to read, and much clearer in text-only (and, I presume, speech or other sequential) browsers. As you point out, it's too easy to insert several bits of data into a row simply because they happen to be short; if these were separated into several list items, they'd make more semantic sense.

As for calling it a "Facts and figures" section, that's an excellent point, and one that I think is more easily (and less clunkily) resolved by using a DIV or other block-level element with headings contained within it. There's no reason we can't add a top-level heading which reads "Facts and Figures" just above the image. Then we can just leave blank alt text for the image.

Also, good point about the color conveying meaning, but this meaning is conveyed in the text (specifically, the light green background for Hydrogen indicates that it's a nonmetal, and the green font indicates gaseous state at room temperature, both of which are already stated in the table). Presumably, someday down the line we can have stylesheets which handle all the heading colors, so it'd be easier to declare, say, class="nonmetal" to get the right colors.

-- Wapcaplet 21:45 30 Jun 2003 (UTC)

---

Good job, Wapcaplet! -- Toby Bartels 18:22 1 Jul 2003 (UTC)

Looks good! I agree that it is more accessible. But I think it would be better (and more semantic) if we could use definition lists (I think there should be a wiki-style markup for them). But I don't like the default way it displays in browsers. Somebody should tweak the CSS so that it looks better. —seav

A definition list may be marginally better in a semantic sense (even though there's more of a heading/content relationship than a term/definition relationship), but I agree that it doesn't look as good. According to the HTML Spec, the term (dt) should be formatted as inline, and the definition (dd) should be formatted as block-level. In plain English, this means that the term should always be on its own line, with the definition in a "box" below it. This could probably be tweaked with CSS, but it would be a kluge. On balance, I think the unordered list is better. -- Wapcaplet 12:54 2 Jul 2003 (UTC)

Start a discussion about Accessibility/Table example

Talk pages are where people discuss how to make content on Meta the best that it can be. You can use this page to start a discussion with others about how to improve Accessibility/Table example.

Start a discussion