Wikipedia talk:Manual of Style/Accessibility

"WT:ACCESS" redirects here. For the related wikiproject talk page, see Wikipedia talk:WikiProject Accessibility.

"WT:COLOR" and "WT:COLOUR" redirect here. For WikiProject Color's talk page, see Wikipedia talk:WikiProject Color.

Discussion at meta:Module talk:Message box § c-Waddie96-20250823092200-Edit protected 2025-08-23

 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)

Wikipedia talk:Manual of Style/Novels has an RfC

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)

Pronunciation of stylised names

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)

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)

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)

@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)

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)

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)

@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)

Should MOS:COLOUR permit multiple colors in some situations?

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)

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)

Template:Goban

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)

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)

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)

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

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)

Question about accessibility of proposed new table

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)

Other languages: how should scientific names be tagged?

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)

@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)

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)

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)

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)

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

<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)

Discussion at Wikipedia talk:Verifiability, not truth § Accessibility concerns

 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)

Discussion notice: alt= text

We_royal would be honored (and surprised) by your participation at: Wikipedia talk:Manual of Style/Accessibility/Alternative text for images#Basics: What makes a good alt= text? ―Mandruss ☎ IMO. 17:29, 14 October 2025 (UTC)

Discussion of Anchors in section heading

A key part of discussion at Wikipedia talk:Manual of Style/Linking#Consensus for the current recommendation to always subst the anchor template within a section header hinges on the impact for accessibility (among other issues). older ≠ wiser 11:31, 22 October 2025 (UTC)

Abbreviations and hover

On 15 January 2011, Dodoïste added to this guideline the text: "Abbreviations are not concerned by this requirements, and may use the {{abbr}} template to indicate the long form of a word." That advice is still in the guideline with slightly different wording. Looking back in the talk archives, it appears that around this time, editors were discovering the "abbr" HTML element was handled well by screenreaders, so that the long form gets read out loud, and the short form is shown visually but the long form is available visually on hover.

Perhaps this made sense back circa 2009-2011, but since then smartphones have become very popular, and they are incapable of hovering. Looking at [1], traffic from mobile devices now exceeds that from desktop computers in some months. This creates a big problem for abbreviations where some readers are confused because they don't know the long form and it's not explained in a legend or nearby prose. For example, Module:Sports table uses abbreviations in table headers like "Pld", "W", "L", "GF", "GA", "PP", and "Pct". From the numbers shown in the body I can guess that "Pct" is "percent", and from context that "W" and "L" are probably "win" and "loss", but the others are mysterious.

What would be the best way to make sure readers on mobile devices can understand abbreviations? Removing the exception completely is one option. This would force table headers to either use the long form or use a legend to expand uncommon abbreviations. Another option would be to require a legend or nearby explanation, and not allow articles to rely on the tooltip to convey information visually since it's not accessible to many or most readers. This would keep the good behavior for screenreaders; for desktop readers it would result in having both a tooltip and a legend, though I expect a lot of people wouldn't know to hover over the abbreviation anyway. -- Beland (talk) 08:58, 3 November 2025 (UTC)

Personally I still support the solution described in phab:T370421. Sjoerd de Bruin (talk) 11:26, 3 November 2025 (UTC)

That suggestion has been sitting around without developer action since 2016, so I think it's safe to assume that it's not going to happen any time soon (unless one of us contributes a patch) and we need to do something else in the meantime. -- Beland (talk) 20:05, 3 November 2025 (UTC)

Honestly this particular problem should be fixed by the browsers. Surfacing this information is something that a long press could easily provide (browsers will already surface information pertaining to links this way), and that it's not is a failing of the browsers rather than specific websites using the relevant HTML correctly (and titles in general). Izno (talk) 19:51, 4 November 2025 (UTC)

I invite you to file bugs with the developers of the major mobile web browsers. I expect it will take a long time for any fixes to be made and widely deployed; in the meantime, we should implement a workaround so our readers can understand our content. -- Beland (talk) 08:51, 5 November 2025 (UTC)

I don't particularly agree with your conclusion or your suggestion on what I should do, given what you're asking will be quite some effort. Sorry. In this case we have not particularly inconvenienced anyone. Users can also just google the terms in any particular case e.g. "Pld in soccer". This is definitely on the browsers here. Izno (talk) 18:00, 5 November 2025 (UTC)

Well, if it's too much work to even ask browser manufacturers to fix the problem, then it's definitely not happening any time soon.

The approach of letting readers find information they need to understand an article on their own from external sources doesn't seem to align with Wikipedia's mission or our general practice. For example, MOS:JARGON doesn't say "don't worry about technical terms; if people don't understand them, they can Google them". It says to try to clarify the article by either removing or explaining jargon, even if that takes up a bit more space. Not using understandable terminology does create an inconvenient barrier to comprehension, for a large portion of our readers.

What's the downside that causes hesitation about expanding abbreviations or adding a legend nearby, whichever is better given the space constraints? -- Beland (talk) 19:20, 5 November 2025 (UTC)

Personally, I feel that a separate legend best serves readers, in addition to other methods such as ones that rely on fine motor control to hover accurately. It's always legible, including when an article is printed/saved to a PDF file. isaacl (talk) 04:53, 14 November 2025 (UTC)

Bwahahaha!

Screenshot of the current revision of this page (permalink)

The page itself has overlapping elements in the section on headings. But seriously, folks, how do you fix this? –LaundryPizza03 (dc̄) 23:36, 7 November 2025 (UTC)

 Works for me But then, I use a proper skin (MonoBook) and not the abomination that is Vector-2022. --Redrose64 🌹 (talk) 23:55, 7 November 2025 (UTC)

@LaundryPizza03 This depends on the width of the page. You cannot have right floating content (accessibility sidebar) above other floating content (shortcuts) like this, while there is also a another sidebar floating above all that. The only way to fix it is to move the last accessibility sidebar below the shortcuts, to remove it, or to use {{stack}} to group the two sidebars into a single right floating element. —TheDJ (talk • contribs) 11:16, 8 November 2025 (UTC)

Seeking feedback on use of transliteration template

I'm not sure whose understanding prevails here, mine or that of User:Ineffablebookkeeper, so I'm presenting this matter here for feedback. In the article on Kiswah, Ineffablebookkeeper wrapped a number of terms in {{transliteration}} tags in running text and in one section heading. This isn't something I'd seen before and I felt it was a mistaken use of that template, on the grounds that, as I stated in the edit summary for my reversion, This isn't what the transliteration is for. It's for tagging transliterations given after non-English words that have been given in the original non-Latin script. It isn't for every word used in English that may also be a transliteration of the word it's borrowed from. At least, that's how it appeared to me.

IB restored the tags, with the edit summary I know it isn't mentioned on the template's documentation – probably it should be – but it's always been my understanding that MOS:ACCESS#Other languages states non-English should be marked up properly for users with screenreaders. It also shows the transliteration template being used for this purpose, as I've done here. Am I wrong in this?

I see IB's point, yet, I've been following articles with anglifications of terms originally in non-Latin scripts for a long time, and I'd swear that, on the other hand, perhaps 99.9999% of similar cases on Wikipedia aren't so wrapped, so, if IB is correct, do we need a massive campaign to fix this broken thing? I thought the matter over, couldn't come to a conclusion that satisfied me, and decided to get input here from others. Largoplazo (talk) 18:27, 13 November 2025 (UTC)

I second this; I'm also puzzled. I've been adding transliteration templates for years, so I'd really like to know if I've been doing it wrong all this time!—Ineffablebookkeeper (talk) ({{ping}} me!) 19:49, 13 November 2025 (UTC)

@Ineffablebookkeeper: Nope, you're good, see below. Paradoctor (talk) 00:19, 14 November 2025 (UTC)

MOS:LANG: Non-English text should be tagged as such, typically with a template like {{lang}}, or one of its derivatives.

99.9999% of similar cases on Wikipedia aren't so wrapped: WP:WIP. It's probably more like 99.5%, though. ;) Paradoctor (talk) 22:43, 13 November 2025 (UTC)

But is it non-English text if it's rendered in sources in English orthography as though it were English text? "Islam", "Muslim", "sharia", "madrasa", and "fatwa" are ultimately transliterations, but they are the words used in English for the concepts they refer to. The last three of these are so English that haters often use them in derogatory ways that make it clear that they don't know what the native terms mean. Largoplazo (talk) 23:46, 13 November 2025 (UTC)

You need to determine if the word is a loanword, on a case-by-case basis. If English dictionaries list it, it is English. Diacritics usually mean the word is not English, but even that has exceptions, cf. café. Paradoctor (talk) 00:14, 14 November 2025 (UTC)

That's just ugly. I don't disagree with the philosophy behind it, but, practically speaking, the whole is-it-English-or-not thing, including coordinating it across the project, amounts to a nightmare, WP:WIP notwithstanding. That said, I yield to Ineffablebookkeeper and respect their devotion to accessibility. Largoplazo (talk) 00:21, 14 November 2025 (UTC)

In most cases, it is straightforward. Do your best, ignore the rest. Someone else will take care of it. Paradoctor (talk) 00:25, 14 November 2025 (UTC)

It is a bit of a nightmare. I only started adding them because I'd been editing articles within my field of interest (Japanese culture), and then started mainly adding language templates in my edits because my life got too busy for more involved article editing. Still, until a better solution comes along, all we can do is raise awareness and hope more editors incorporate them into their edits.

(Also, it's easier to determine loanwords or not if you're keeping your edits within topics you're more familiar with, which is how I go about things, but I recognise that other editors don't take this approach.)—Ineffablebookkeeper (talk) ({{ping}} me!) 14:59, 14 November 2025 (UTC)

P.S.: MOS:LANG: Loanwords are not foreign-language text (see WP:MOS#Non-English terms), and should not be marked with an IETF tag.

And this one: MOS:SCIENTIFIC: scientific names are never marked up with {{lang}} or related templates. Paradoctor (talk) 00:29, 14 November 2025 (UTC)

As a screen reader user who almost always has language detection switched off (because I don't like hearing my speech synthesiser's voice change randomly), I wouldn't use a language tag for just transliterations like that. Not all non-English speech synthesiser voices are set up to read the Latin alphabet, especially in the case of eSpeak (which sometimes spells the words out or reads them with a British accent). The Japanese voice that can be added to my screen reader JAWS will occasionally not read certain combinations of Latin characters at all (probably in combinations that would never occur in actual Japanese text ... like it won't read a line containing the word "Chinese"). Some screen reader users really like language tags; others really don't. For what it's worth we have wikt:Kiswah, indicating that it may well be a loanword. Graham87 (talk) 04:23, 14 November 2025 (UTC)

Ignoring existing tags can be done, as you know, but guessing tags that aren't there can't, so the guideline is at the right place there.

we have wikt:Kiswah: Uhh, WP:USERGENERATED. In this particular instance, MW and OED concur, but generally, WT:ATTEST seems more inclusive than other dictionaries. Paradoctor (talk) 04:51, 14 November 2025 (UTC)

Clarity surrounding chart headers/table captions

Lately, I've been seeing more and more chart headers/captions being removed from music articles. From my understanding, these were brought in back in a 2020 discussion for a consensus to accomodate people who needed screen readers. Still on this article, it still mentions about tables needing headers for accesibility reasons. I've increasingly noted @Binksternet:, who's an admin with extended privleges, removing the chart headers and replacing them with "sronly|Chart performance" template tags [2]. I used to be under the pretense that the headers were originally needed for presentation purposes, but even then, would still serve a function for accesibility functions for wikipedia readers with specific disabilities. I've currently as of now, only seen him make these specific edits, so I wasn't sure about the consensus among the community regarding these overall. Are we still required to use chart headers for us music editors? Or do we follow suit with what he's doing? On another note, I've previously came into clashes with @Magatta: regarding personal concerns about excessive headers being used to ridiculously absurd amounts in each chart sections because there are around ten different seperate tables in one chart section as such on "Mr. Brightside" and other similar song articles which constantly chart on year-end charts in loads of different regions on an annual basis, which is a cause of concern for those with dyslexia and other similar hyper sensory overload disorders, as well as becoming an overall mess presentation wise. Is there something that we could do more of to tackle accesibility for ALL of those with disabilities? What should we ACTUALLY be doing in regards to table headers for us lot who edit music articles or other similar topics that require tables? I would appreciate it if we could get some more clarity regarding this, many thanks. Rockmusicfanatic20 (talk) 22:23, 14 November 2025 (UTC)

There's a discussion underway at Wikipedia talk:Manual of Style/Tables#Should captions be mandatory on all data tables?

The question is whether table captions are required for the sighted reader, or are they required only for non-sighted readers. My position is that they should not be required for sighted readers because they add too much clutter in general, repeating the same information that may be seen in a section heading directly above, or in the chart itself. Medxvo noted that a relevant RfC was closed in May 2020 but during the same time RexxS was creating Template:Screen reader-only or Template:sronly, the presence of which would have greatly affected the RfC.

Note that this discussion includes the caption parameter in Template:Certification Table Top, and in other data table templates which may use different terminology.

Here's a diff showing my implementation at the Tommy rock opera page.

I think the table header caption should be optional for the sighted reader. It can come in handy in certain cases. But if we require it in all cases we would be adding a large amount of visual noise. Binksternet (talk) 23:01, 14 November 2025 (UTC)

@Rockmusicfanatic20 and Binksternet: Please see my comments at Wikipedia talk:Manual of Style/Tables and check that you have used the correct terminology above, particularly concerning the word "header". --Redrose64 🌹 (talk) 09:26, 15 November 2025 (UTC)

All of my concerns are regarding the caption. I have no problem with column headers or row headers. I think the caption should not be required for the sighted reader because it creates so much clutter on the page. Binksternet (talk) 14:11, 15 November 2025 (UTC)

So if your sentence I think the table header should be optional for the sighted reader. is correct, I oppose it. Removing column headings is detrimental for all users, sighted or otherwise. --Redrose64 🌹 (talk) 14:48, 15 November 2025 (UTC)

Yes, I agree. Only the caption is superfluous. We should be changing the guidance about captions, recommending that the caption be supplied at all times to assist screen reader apps, but made optional for sighted readers. We should be recommending that Template:Screen reader-only should be utilized when the sighted reader does not need the redundant caption. Binksternet (talk) 15:50, 15 November 2025 (UTC)