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 falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
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
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
The Doctor arrives at the Time Hotel, an establishment that allows visits to historical points. The Doctor enlists the aid of Trev, a hotel employee, as he investigates a mysterious briefcase. [...]
In a recent FLC nomination, the usage of {{Episode table/part}} (the "Special" row) was suggested against, as it was in violation of COLHEAD. My question is, how is that particular colspan'ing "Special" row any different to the colspan'ing summary row directly below the episode details? -- Alex_21TALK06:58, 17 May 2025 (UTC)[reply]
@Alex 21: Here's the HTML for the above, stripped down to just the first cell in each row, and most attributes removed:
<tableclass="wikitable plainrowheaders wikiepisodetable"style="width:100%"><tbody><tr><th><abbrtitle="Number">No.</abbr><br>story</th></tr><tr><tdid="Special"><b>Special</b></td></tr><tr><thscope="row">312</th></tr><tr><td><divclass="shortSummaryText"style="max-width:90vw;position:sticky;left:0.2em"><ahref="/wiki/Fifteenth_Doctor"title="Fifteenth Doctor">The Doctor</a> arrives at the Time Hotel, an establishment that allows visits to historical points. The Doctor enlists the aid of Trev, a hotel employee, as he investigates a mysterious briefcase. [...]
</div></td></tr></tbody></table>
The problem, as I see it, is that in the first column there is a <th>...</th> element below a <td>...</td> element. --Redrose64 🌹 (talk) 13:13, 17 May 2025 (UTC)[reply]
Oops, forgot about this. So, the issue isn't the Special row at all? It's the 312 (<th>...</th>) after the Special row (<td>...</td>)? If the 312 <th>...</th> was updated to 312 <td>...</td>, this would allow the Special row? -- Alex_21TALK04:18, 1 June 2025 (UTC)[reply]
Syntax aside, the visual problem is that the "Special" and summary row dont match the column headers. The problem is compounded if one tries to programmatically parse the data, such as with screen readers. —Bagumba (talk) 04:58, 1 June 2025 (UTC)[reply]
So, if they matched column headers, COLHEAD would no longer be applicable here? I'm attempting to make them match accessibility standards, and be able to restore them to featured lists that have required their removal. -- Alex_21TALK00:35, 2 June 2025 (UTC)[reply]
That's my basic understanding. Optionally consider denoting a special with an asterisk, dagger, etc. explained in legend, or placing the episode summary as regular prose outside the table. —Bagumba (talk) 01:54, 2 June 2025 (UTC)[reply]
Separating parts with {{Episode table/part}} is standard in WP:TV, and the episode summary outside is not possible due to the nature of the {{Episode list}} template, which includes multiple episodes and summaries after each other.
To confirm, would the "Special" colspan'ing row need to be <th>...</th>, or would the 312 cell need to be <td>...</td>? -- Alex_21TALK04:37, 2 June 2025 (UTC)[reply]
Indentation within quotes
Suppose that within a Template:Blockquote, there's something that requires indentation - perhaps because the quote is quoting something, or the quote include a poem, etc. Suppose further that this should play nicely with all editors and be consistent - perhaps there are multiple quotes on the page with indented sections within them, and we want to easily ensure the indents all line up across the page. Is there an accepted way to do this? As best I can tell, the only good option is colons a la talk pages (despite this being discouraged as they're not really definition list items). Trying to throw a wild <div style="margin-left: 5m;" >Stuff</div> in the middle doesn't work and wouldn't play nicely with VE even if it did, so that seems out. To be clear, I'm fine with using colons, but just curious if this has come up before. SnowFire (talk) 01:16, 4 June 2025 (UTC)[reply]
MOS:INDENTGAP is indeed on this page, which has about the most detailed guidance we have on indents, so I disagree that this is the wrong place for it. (Wikipedia:Indentation is about talk pages, not prose in article space.) SnowFire (talk) 14:38, 4 June 2025 (UTC)[reply]
Expanding best practice with ARIA and other attributes
The W3C has a standard called WAI-ARIA (Web Accesibility Initiative: Accessible Rich Internet Applications Suite) for defining "richer" content for accessible interaction. ARIA includes a bunch of roles such as "buttons" and "emphasis" to deal with the fact that semantic tags have limitations that prevent their use in many situations:
<button> cannot be styled at all and that, naturally, is bad for design purposes. Every button you see on MediaWiki's "OO-UI" widget kit is a styled element, made accessible through the ARIA attribute role=button.
<em> is designed for inline situations. What if you want to emphasis an entire table cell? Hence role=emphasis.
It, of course, remains more ideal to use semantic tags when you can. But there are times when they cannot fit the bill without unholy amounts of modification such as sticking a display: block on an inline element. That is when ARIA comes in. Like I've mentioned we already use ARIA by virtue of our default skin(s), so it is only logical that we use it in our content when necessary. (The role= attribute is not rejected by MediaWiki's HTML filter, I've checked.)
ARIA/attribute edit proposal
The current text shall be changed to (unchanged parts indicated with no markup and shortened with [...]):
Best practice: wiki markup and, CSS classes, and semantic attributes
In general [...] an individual to choose their own theme.
It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide.
While CSS classes are useful for styling, they do not automatically provide semantic meaning for assistive technologies. To improve accessibility, consider using WAI-ARIA attributes such as role= where appropriate, especially when creating custom components or when the semantic meaning of an element is not clear from its HTML tag alone. For example, if a <div> is used to create a navigation region, add role="navigation" to clarify its purpose for screen readers. (This is already done with many of the standard templates such as {{navbox}}.) Non-ARIA attributes such as scope on table headers are also important for accessibility, as they help screen readers understand the structure of the table.
I'm about to be incommunicado, and also don't have the equipment to check this myself at the moment. At this Reddit post, somebody asked,
Second scrollbar on some articles makes navigation with voice control not possible
Hi,
I am mostly bound to using voice control on my tablet due to a disability.
Due to this, I noticed that some, but really only some, articles have a second scroll bar. This makes a navigation via voice control not possible (emulated scroll down doesn't work, since scrolling down with a finger in the middle of the page also doesn't work).
You can actually see the second scroll bar on the right hand side of the image next to the overview block. The second scroll bar exists not only in Firefox on Android but also on Chrome, there's no difference.
What is this second scroll bar and why does it only exist on some articles? Is there any way to remove them?
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]
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,
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]
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.
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]
