Experiments

Table vs List architecture

The purpose of this activity was to experiment and prove a new architecture for an old feature that was being updated. The old feature displayed a list of workers and metadata describing the worker’s activities.

The problem with the existing functionality is that the list was not built for accessibility and did not meet HTML spec standards for a table or list layout. The layout does not provide any structure for a screen reader to announce, and the data presented visually does not include any context.

Process

I used a recorded interview with a customer who is blind and uses a screen reader to watch how he uses the feature. He stated that this should be a table so the screen reader would be able to understand the structure and context of the data. Our accessibility leader felt that it should be a list.

My objective was to prove whether this “list” should be built as an HTML list or as an HTML table and then style it to match the new design. I did this by building the feature 3 different ways (description list, ordered list, and table), using strict, semantic HTML, and then applying CSS styles.

Justification

The reason I used both description list and ordered list was to experience the screen reader and how it handles having separate property and value (description list) read aloud vs a string of text representing property and value read aloud at one time. The description list proved to be too noisy and verbose and required too many keyboard clicks to be helpful as compared to using a single string of text per item.

Videos

1. Semantic description list (unstyled)
2. Semantic ordered list (unstyled)
3. Semantic Table (unstyled)
4. Final Table (styled)

Examples

Description List

Ordered List

Semantic Table

Styled Table

Result

The result of this experiment was to build the feature following the table spec, using CSS grid to modify the visual alignment of the cells to look like the list.

Semantic Table

Styled Table

Final with expand/collapse rows

Lessons learned

1. Visually delightful does not mean accessible

   The original design, though delightful, did not account for or describe an accessible experience and was not usable for someone using a screen reader

2. Accessible does not mean delightful experience

   Using the description list nor the ordered list, though completely accessible, did not provide a delightful experience for someone using a screen reader

3. Building to spec does not mean it is a delightful experience

   Simply building to spec without considering the layout and style does not mean the experience will be delightful

4. CSS Flexbox negatively affected the screen reader behavior using the table, which dictated the architecture of the table

   Switching to CSS Grid removed this issue and maintained the expected style

Further enhancements

A future redesign changed the visual layout of the feature, remove the card list style and replacing it with a table style. The architecture was already a table, so all that was needed was to re-style the CSS and modify a few columns.

Table Redesign