SC 1.3.1 and lists with "space-between" layout

[pete-murphy]

SC 1.3.1 is for ensuring that "information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes" (like when read by SR). There's a failure example using white space to implement a table layout: https://www.w3.org/WAI/WCAG22/Techniques/failures/F34. The failure case there seems obvious, especially because the reading order is all jumbled.

I'm wondering about a less obvious case where data is presented as a list (instead of a table) using flex for example, where each list item uses space-between alignment, which ends up looking like a two-column layout. Would this fail if marked up as <ul> instead of <table> (because of relationships implied by "column-like" formatting)?

[TestPartners]

I would say this is ok as long as there is a programmatic relationship between each item and its category, price and date. In this particular case, a description list is arguably most appropriate, although an unordered list would be ok. In my view, if a visual appearance can be programmatically represented in more than one way, 1.3.1 does not require that it is programmatically represented the same way as the visual appearance. For instance, it may well be reasonable for a two-column data table to be programmatically represented as a list in some cases. For data tables with more columns, I think that argument becomes weaker. I would also argue that this example isn’t really tabular data because the price and date would be in the same column. Steve Green Managing Director Test Partners Ltd From: Pete Murphy ***@***.***> Sent: 24 July 2025 21:56 To: w3c/wcag ***@***.***> Cc: Subscribed ***@***.***> Subject: [w3c/wcag] SC 1.3.1 and lists with "space-between" layout (Discussion #4504) SC 1.3.1<https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships> is for ensuring that "information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes" (like when read by SR). There's a failure example using white space to implement a table layout: https://www.w3.org/WAI/WCAG22/Techniques/failures/F34. The failure case there seems obvious, especially because the reading order is all jumbled. I'm wondering about a less obvious case where data is presented as a list (instead of a table) using flex for example, where each list item uses space-between alignment, which ends up looking like a two-column layout. image.png (view on web)<https://github.com/user-attachments/assets/20404d36-f1fe-4ac6-b45f-72469060c748> — Reply to this email directly, view it on GitHub<#4504>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACSY766CIVUGVLNEJQLTXFT3KFB5XAVCNFSM6AAAAACCJ5V4UWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGYZTAMJTGU>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[pete-murphy]

For instance, it may well be reasonable for a two-column data table to be programmatically represented as a list in some cases. For data tables with more columns, I think that argument becomes weaker.

this example isn’t really tabular data because the price and date would be in the same column

Hm, my actual use case (activity history, like what might be synced from Apple Health) is somewhat different from the screenshot above in ways that could be meaningful then:

• the leading icon is used as the sole indicator of whether an entry was automatically synced or manually-entered
• the right-aligned "last visual column" contains a timestamp & date

I think this UI would probably make less sense as a description list (there's no obvious term and definition pairing for each row), but might also not make sense as a table (because activity type & duration would end up in same column).

[TestPartners]

It looks like Running, Yoga and Hiking would be the term in a description list or the row header in a table. It would take a bit of CSS ingenuity to achieve the required appearance, but I'm sure it's possible. It's probably easier to do with a list. The entry method, duration, date and time would all go in separate <dd> elements - you're not limited to one for each <dt> element.