Ordered Lists and CSS - Are we losing semantics?

| | Comments (4)

I'm about to question a pearl of standards/accessibility conventional wisdom and ask if we need to rethink how ordered lists are coded in terms of CSS. That is, are we putting too much semantic information in the CSS?

The standard mantra for ordered list OL standards is to use stylesheets to change list numbering types as in the examples below. Another is to make sure that nested lists change numbering schemes between levels to mark a change in list level.

Numeric
list-style-type:upper-latin
Capital Alphabetical
list-style-type:upper-alpha
Lower Roman
list-style-type:lower-roman
  1. Item 1
  2. Item 2
  3. Item 3
  1. Item A
  2. Item B
  3. Item C
  1. Item i
  2. Item ii
  3. Item iii

This is a change from the old days when you would specify numbering schemes and start points with embedded attributes (e.g. <list type="A"> if you wanted capital letters).

From a processing level it makes sense because all ordered lists are numbered lists in disguise. And since modern screen readers appear to recognize the new styles, it appears that a major hurdle is cleared.

On the other hand, this means that all numbering scheme information is in a CSS? That's fine...unless a user chooses to ignore your stylesheet and use a custom style sheet. Then the potential is for a nested listed with distinct numbering levels to become an inaccessible nested list using the same numbering scheme at all levels. Hmmm.

Nested List with CSS Nested List, CSS Disabled
  1. Top Level Item 1
    1. Second Level 1
    2. Second Level 2
      1. Third Level 1
      2. Third Level 2
  2. Top Level Item 2
  3. Top Level Item 3
  1. Top Level Item 1
    1. Second Level 1
    2. Second Level 2
      1. Third Level 1
      2. Third Level 2
  2. Top Level Item 2
  3. Top Level Item 3

I'm not sure how serious a problem this is, but it is a possible gotcha. The line between "presentation" and "semantics" can be a little fuzzy at times. Of course, if I want my Hebrew numbered lists, I have to rely on the new styles.

Postscript (Feb 13)

This issue is being discussed on one of the language tech list, and someone else made the same objection (I'm glad it's not just me).

4 Comments

Brad Kozlek Author Profile Page said:

I might be getting way too impractical here, but....

As soon as you use an OL and LI tags, you are describing a structure in which data fits. How this structure is represented visually could be any number of ways. It could be represented as a tree diagram or a series of tables.

I think leaving the representation up to the specific client makes more sense in regards to accessibility. Even if a nested list is rendered with the the same numbering scheme on all levels, I wouldn't see anything wrong with a screen reader reading it with different schemes on each level.

Of course, there is the issue of referring to the number of items in the text of the page, for example, "Number 3 above ...". But if that is the case, I have to wonder if using an OL tag makes sense at all.

ELIZABETH J PYATT Author Profile Page said:

I think your reasoning is the standard reasoning, and I agree that for a UL it doesn't matter quite so much. I think the choice of bullet visuals is pretty much presentational.

I think my real concern with OL is that if you have the same numbering scheme at all levels, you lose a sense of hierarchy or which level an item is at, and it is important information.

For instance you comment:
"...if a nested list is rendered with the the same numbering scheme on all levels, I wouldn't see anything wrong with a screen reader reading it with different schemes on each level."

But the numbering scheme HAS been the indication of list level to the user. It was fairly unusable for screen readers in the past when the same numbering scheme was used at all levels, but now I think the modern ones indicate that a sub list is about to be read which is a little better.

The real concern is that if a user switches to an alternate style sheet, the information on numbering scheme could be lost and something like a reference to an item within a table of contents (e.g. See "Section I.A") could be really unusable if the list becomes "Section 1.1" because of a CSS issue.

This is a case where CSS is controlling semantics which is a little backwards. Also, it should be noted that Section 508 requires that documents remain "readable" if CSS is disabled.

If you can't use an OL because a reference might be lost, then why do we have OLs at all?


Brad Kozlek Author Profile Page said:

To be honest, I am not sure why we have OLs. If the item numbers are being used for reference, I am not sure I rely on the browser to construct them based on the semantic information. I'd hard code them.

ELIZABETH J PYATT Author Profile Page said:

Maybe - but it's nice to have the ability to add and delete items and not have to manually renumber (e.g. a set of instructions, table of contents). Even if you have to watch out for references.

Personally, I don't have a problem with the old way (specifying numbering, start number in the HTML semantics)...even though I think CSS is a good solution for ULs

As your comment points out, there's a lot to think about philosphically.

Leave a comment