Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial

This is the talk page for discussing improvements to the Manual of Style/Accessibility/Data tables tutorial page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: 1, 2: 250 days

MOS:COLHEAD potential workaround?

Can MOS:COLHEAD violation in this case be worked around by adding "id=colX is empty. In row13 you can found...." or a hidden comment with a similar message to indicate to screen readers that more content can be found in the next row instead of rearranging the rows? Qwerty284651 (talk) 23:55, 2 June 2024 (UTC)[reply]

That whole table is messed up so trying to workaround one bad part of it, won't really "fix" it. Look at the "Career statistics" section, 5 of the 9 rows have cell content unrelated to the column headers. Separate the tables, make better column headers, remove bad usage of bold. Not everything needs to be in one giant table. Gonnym (talk) 06:30, 3 June 2024 (UTC)[reply]

@Gonnym, I proposed an improved version (pinging those involved in creating the new design @Fyunck(click) and Unnamelessness:) which passes MOS:COLHEAD in my project's community, but people are used to one design, prevalent in 100s of tennis BLPs. The new look meets accessibility criteria WCAG for screen reader users but offsets the sighted who are used to the old design...a balancing act.

Maybe remove the rows and replace them with {{notes}} or {{efn}}? Qwerty284651 (talk) 16:42, 3 June 2024 (UTC)[reply]

Yeah, not surprised. There are some places I'll never touch just because I don't want to deal with that type of editors. Gonnym (talk) 16:48, 3 June 2024 (UTC)[reply]

@Gonnym, I get you. I am going to make a push in favor of the visually impaired. Hopefully, it sticks. The minority needs to be tended to as well not just the ones blessed with the gift to see. Qwerty284651 (talk) 16:54, 3 June 2024 (UTC)[reply]

That is something I originally proposed, but you know, some kinds of compromise have to take as this is Wikipedia. :) Unnamelessness (talk) 06:08, 4 June 2024 (UTC)[reply]

I know. It is the bitter sweet truth. You can't please everybody. Qwerty284651 (talk) 10:21, 4 June 2024 (UTC)[reply]

Cells on multiple rows

Hi, are the cells spanned on multiple rows accessible? E.g., DC Extended Universe#Films: the correct way is to split the "Zack Snyder" cell into two cells with the same date or are they just fine as they are? Redjedi23 (talk) 14:43, 21 June 2024 (UTC)[reply]

I state that because if I try to read the Batman v Superman row, the Apple VoiceOver skips the director's name Redjedi23 (talk) 15:41, 21 June 2024 (UTC)[reply]

They're fine as they are. VoiceOver isn't that good with this kind of thing. Graham87 (talk) 15:51, 21 June 2024 (UTC)[reply]

@Graham87 I get the same result with NVDA Redjedi23 (talk) 16:01, 21 June 2024 (UTC)[reply]

@Redjedi23: Same, but also those sorts of tables aren't meant to be read linearly ... they're supposed to be read with table navigation commands (control+alt+arrows in NVDA's case), which works as expected. Graham87 (talk) 17:39, 21 June 2024 (UTC)[reply]

But in this way the header column loses its meaning, right? Redjedi23 (talk) 18:01, 21 June 2024 (UTC)[reply]

Not really. Screen reader users will just get used to having a blank cell (with information hopefully about the row spans) and things will be fine. Graham87 (talk) 18:16, 21 June 2024 (UTC)[reply]

Colgroups and rowgroups

In Wikipedia:Manual of Style/Accessibility/Data tables tutorial#Complex tables it says "To clearly define relationships and avoid accessibility issues, use ! scope="colgroup" colspan="2" | when a column header spans two columns and ! scope="rowgroup" rowspan="2" | when a row header spans two rows..." Can a combination of those be used when a column spans multiple rows scope="rowgroup" colspan="2" and when a row spans multiple columns scope="colgroup" rowspan="2" in complex tables? Qwerty284651 (talk) 12:00, 13 August 2024 (UTC)[reply]

Better describe the problem of missing captions for screen reader users (SRUs)?

Do we need to expand on the issue of missing captions? I ask because so many data tables do not have a caption, suggesting that editors are unaware of the problems caused where one is missing. For example, a SRU can call up a list of tables on a page, each labelled by their caption. Where the caption is missing, the table is announced along the lines of "6 columns, 20 rows" by VoiceOver. I suspect that other software says something similar. Unless the user is a mind-reader (!), this is no good at all. What do others think? What can we do? I do not want to spend my whole editing career adding captions to existing tables! CrazyBuilder talk 20:08, 7 October 2024 (UTC)[reply]