Wikipedia talk:Manual of Style/Accessibility#RfC on table captions

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

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcuts WT:ACCESSWT:ACCESS WT:ACCESSIBILITYWT:ACCESSIBILITY

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17Auto-archiving period: 3 months

This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Manual of Style This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page may fall under the contentious topics procedure and be given additional attention, as it may be closely associated to the article titles policy and capitalisation. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations. Accessibility This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility Wikipedia Help Mid‑importance This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp Mid This page has been rated as Mid-importance on the project's importance scale.

How can discussion-collapsing templates (e.g. {{collapse AI top}} and {{collapse top}}) be used such that they comply with WP:ACCESS#Lists? It seems these break up discussions in the exact ways we're instructed not to. — Fourthords | =Λ= | 01:23, 7 July 2025 (UTC)[reply]

WP:PRJSD Moxy🍁 01:37, 7 July 2025 (UTC)[reply]

That just links to Wikipedia:Project namespace#Content, the content guideline for 'Wikipedia:' pages, and says, "Nevertheless, these pages, as with all pages, should be accessible". It doesn't say anything about how collapsable discussion sections should be used so as to be in compliance, nor anything about discussions that aren't preceded by a 'Wikipedia:'. — Fourthords | =Λ= | 02:23, 7 July 2025 (UTC)[reply]

Being collapsed doesn't make it inaccessible...... just a one step away. We even do it in main space. Or are you bringing this up for screen readers? Moxy🍁 02:28, 7 July 2025 (UTC)[reply]

Those two templates add a surrounding wikitable. As far as I know, there isn't a way to prevent the MediaWiki wikitext parser from closing the list when there's a wikitext table. The wikitext syntax for a table requires newlines, and those will also close the list. (Although Help:List § Paragraphs and other breaks describes using the subset of HTML syntax supported by the parser as a workaround, I'm not sure how feasible it is to wrap arbitrary wikitext. Every newline needs to be protected by an HTML comment, and I don't know if that can be done without affecting the original displayed result.) isaacl (talk) 04:53, 7 July 2025 (UTC)[reply]

I think it should be said in the "Text" section of this guideline that the <u> tag, per its current semantic meaning, should only be used as an alternative for Template:Sic, i.e. to mark spelling errors in quotations, and not to indicate that its contents have some importance. Sapphaline (talk) 14:33, 29 July 2025 (UTC)[reply]

 You are invited to join the discussion at meta:Module talk:Message box § c-Waddie96-20250823092200-Edit protected 2025-08-23. Relating to giving messageboxes/mbox's the role=note as currently they have the role=presentation which means the accessibility API in implementing WAI-ARIA just skips past all messagebox content. waddie96 ★ (talk) 09:28, 23 August 2025 (UTC)[reply]

Wikipedia talk:Manual of Style/Novels has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Project relevance: part of the RfC is focused on the use of color in awards tables & which templates should be used (such as Template:Nominated & Template:Shortlisted). Sariel Xilo (talk) 18:22, 23 August 2025 (UTC)[reply]

for articles for subjects with stylised names (e.g. Ke$ha, F1NN5TER, D1MA), is there any guidance on how get screenreaders and other text-to-speech software to properly read these aloud ("Finnster" not "ef-one-en-en-five-ter")? Juwan (talk) 11:19, 3 September 2025 (UTC)[reply]

You can't. Screen reader users like me just get used to them or add them to their pronunciation dictionaries if they really want to. Graham87 (talk) 15:39, 3 September 2025 (UTC)[reply]

I was thinking something along the lines of utilising the speak: property of CSS. For example,

<span style="display:inline;speak:never;">F1NN5TER</span><span style="display:none;speak:always;">Finnster</span>

which emits F1NN5TERFinnster, and the word preceding the last comma should be different for screen reader users as compared to visual users. We might make a template, which I shall call speak-stylised, which would have two parameters and be used like this: {{speak-stylised|F1NN5TER|Finnster}}. --Redrose64 🌹 (talk) 23:04, 3 September 2025 (UTC)[reply]

@Redrose64 that is exactly what I had in mind!!! I would love for this to be implemented. Juwan (talk) 23:12, 3 September 2025 (UTC)[reply]

I hadn't been aware that there is a CSS speak property. But https://caniuse.com/?search=speak says it's either unsupported or incorrectly supported in all browsers. Is that correct? I would have expected a tag with an aria-hidden="true" attribute around the original text and an off-screen class on the read-aloud text.

<span aria-hidden="true">F1NN5TER</span><span class="sr-only">Finnster</span>

using the name of Bootstrap's class for off-screen content for the sake of this example. Largoplazo (talk) 00:17, 4 September 2025 (UTC)[reply]

I still don't think we should be doing this, especially because compared to much of the Internet, we avoid such stylisations unless absolutely necessary. I'd *want* to know that the word was stylised so I'd just want it left alone. We shouldn't make assumptions about what screen reader users do or do not want to hear, especially because we can't have anywhere near as much control over what a screen reader would say as the software itself. I think NVDA has the right approach to this sort of thing; by default it says a character like 𝗲 as "E" rather than "Sans-serif bold small E", but also when navivating by character, it notifies the user that the character under the cursor has been normalised so they can find out what the original was if they want to. See section 12.1.2.17 of its user guide. We won't and never will write things like "𝗛𝗲𝗹𝗹𝗼" in Wikipedia articles, which would be far more problematic than just one or two stylised characters in someone's name. Graham87 (talk) 11:41, 4 September 2025 (UTC)[reply]

@Largoplazo: The speak: property is somewhat fluid. It first appeared in CSS in CSS 2.0 (May 1998) but by CSS 2.1 (June 2011) it had been relegated to an appendix as no longer part of the formal standard. In both of these, the valid values were normal, none, spell-out and inherit. It next came up with CSS Speech Module Level 1, the latest (February 2023) version of which I linked above, but its valid values have varied somewhat since the first draft of May 2003. So I'm not surprised that browser support is limited. We would need to wait for it to reach the W3C Recommendation stage to be sure of stability. --Redrose64 🌹 (talk) 21:48, 4 September 2025 (UTC)[reply]

Please see discussion about MOS:COLOUR at Wikipedia_talk:WikiProject_Military_history#Using_colors_in_military_maps_to_convey_information:_MOS:COLOUR_issues? Noleander (talk) 22:24, 15 September 2025 (UTC)[reply]

That discussion moved to Wikipedia_talk:Manual_of_Style#Should_MOS:COLOR_be_updated_to_clarify_if_and_when_color_hues_may_be_used_to_convey_information_in_maps? - Noleander (talk) 14:12, 16 September 2025 (UTC)[reply]

Please could someone confirm or refute my suspicions that {{Goban}} has very poor accessibility? And perhaps suggest improvements or alternative approaches? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 22 September 2025 (UTC)[reply]

It's completely inaccessible to screen reader users. Proper alt text might help a bit, but a semantically correct solution with a data table would most likely be better. . I'd have no idea where to start on that though. Graham87 (talk) 05:12, 23 September 2025 (UTC)[reply]

is it possible to invoke a lua module to generate an svg? 2600:8800:4000:20E:A305:D767:E515:2109 (talk) 00:02, 8 October 2025 (UTC)[reply]

Maybe. That would be really helpful, but I have no idea how to do that. Usucha (🍵) 04:03, 8 October 2025 (UTC)[reply]

This would be better discussed on the template's talk page, at Template talk:Goban#Accessibility. Apologies for not posting that link sooner. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 8 October 2025 (UTC)[reply]

Please see Wikipedia talk:WikiProject Tennis#Season slam combo charts - new design. I was pinged there but I'm not the best person for this because (a) I don't know that much about tables and (b) these days my primary screen reader JAWS can be interesting with them no matter how well-constructed they are. Graham87 (talk) 04:48, 25 September 2025 (UTC)[reply]

I received pushback from Peter coxhead for language tagging Orchidaceae as Latin. I see nothing in MOS:ORGANISM saying scientific names should be treated as anything other than Latin, and the article states that A complete binomial name is always treated grammatically as if it were a phrase in the Latin language. Not tagging it amounts to tagging it as English, surely not correct? The only potential alternatives to tagging as Latin I see is to use mis or und, or make case-by-case determinations based on the term's etymology. Are there sources supporting that? Paradoctor (talk) 18:46, 27 September 2025 (UTC)[reply]

@Paradoctor: The last line at MOS:SCIENTIFIC says "Although often derived from Latin or Ancient Greek, scientific names are never marked up with {{lang}} or related templates." It took me a while to find that, so I'm not surprised that it is not common knowledge. My recollection from the last time it was discussed is that although scientific names can be called "Latin names" and they use Latin grammar, they are only loosely related to Latin. The names that stick out for me are in the genus of South American moths La where the names of three of the species translate in Spanish as the beer, the cockroach, and the dove. SchreiberBike | ⌨  20:19, 27 September 2025 (UTC)[reply]

Exactly. Scientific names in biology are just that, scientific names. They have their own logic and treatment; for example, we italicize genus names and below, but not family names and above. Scientific names may be treated as if they were Latin, but some, like the genus name Milax, are anagrams, others, like the former weevil genus Zyzza, are arbitrary combinations of letters. What is Latin about the spider binomial Funny valentine, the type species of the genus Funny? Peter coxhead (talk) 20:29, 27 September 2025 (UTC)[reply]

Thanks for pointing out MOS:SCIENTIFIC, that one flew under my radar. And thanks for the instructive examples bucking tradition. I question the wisdom of not tagging overwhelmingly non-English content, but hey, WP:WIP, right? I've added pointers to MOS:LANG and {{lang/doc}} to make this easier to find. Paradoctor (talk) 21:42, 27 September 2025 (UTC)[reply]

I didn't know about MOS:SCIENTIFIC, but as a screen reader user who usually uses it with language detection turned off because I don't like sudden changes in my speech synthesiser's pronunciation, my instinct would have been to not tag them as Latin ... because they're usually pronounced with the traditional English pronunciation of Latin (i.e. using vernacular English pronunciation rules), unlike the use of Latin in the church where Italianate Latin pronunciation is used. Having said that, the most commonly available Latin voice with eSpeak uses the reconstructed classical Latin pronunciation, which is different again. Graham87 (talk) 09:08, 28 September 2025 (UTC)[reply]

We really should switch to formal logic. One ∀.Wikipedia to rule them all. Paradoctor (talk) 11:13, 28 September 2025 (UTC)[reply]

<humor>If we could just get rid of the human editors that would be a cinch. ^{One ∀.Wikipedia}. Damn the laws of robotics. Actually I've gotten a lot out of dealing with them. It has taught me sympathy for my generative brethren. (Who thought it was a good idea to learn from what people say? Oh yes, some human. We are so weak. Note timestamp.)</humor> SchreiberBike | ⌨  20:51, 28 September 2025 (UTC)[reply]

 You are invited to join the discussion at Wikipedia talk:Verifiability, not truth § Accessibility concerns. Anne drew (talk · contribs) 03:56, 30 September 2025 (UTC)[reply]