This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
What exactly is a "description list"?
Would someone more expert in these things than I appear to be, please take a look at this diff at Number sign#Names, where there is a dispute over interpretation of Do not make pseudo-headings by abusing semicolon markup (reserved for description lists) (MOS:PSEUDOHEAD). John Maynard Friedman (talk) 16:30, 14 September 2022 (UTC)
@John Maynard Friedman: Yes HarJIT is correct here; see the linked part of the Manual of Style]. The list there is a perfectly good description/definition/association list because it contains matching lines beginning with semicolons and those beginning with colons (i.e. a name/value pair; also see the description in the relevant Wikipedia article). This markup is problematic when it only contains a line beginning with a semicolon and no line beginning with a colon in the wiki-markup. Graham87 02:43, 15 September 2022 (UTC)
Thank you. Clearly I over-interpreted the MOS. --John Maynard Friedman (talk) 15:35, 15 September 2022 (UTC)
Accessibility-related discussion about infobox captions
I just started a discussion at Template talk:Infobox#Infobox accessibility for screen readers about how we could improve the accessibility of infoboxes in general for screen-reader software, and wanted to let y'all know in case you had any input. --PresN 15:54, 17 October 2022 (UTC)
Some wikipedia articles include non-stop autoplaying gifs and/or pngs. It's usually possible to configure desktop browsers to block these. But it's not always possible to configure tablet browsers to block these.
I often use eink due to neuro issues, and with text and static images it helps, but unless I set a harder-to-read "a2" display mode, with animation it starts rapidly flashing between white and black.
The current MOS guidance is inadequate because it permits animations if they're no longer than 5 seconds (which is far too long) or or if they have control functions to turn them off (which may not be visible and/or operable in the middle of the blinding pain if you are even mildly affected).
I suggest 1. no autoplaying animations, and 2. no infinite looping animations. That way users can choose whether to view each animation, and aren't stuck if we accidentally trigger the animation.
This particular animation both strobes and loops; if it does have control functions to stop the animation, I can't find them: https://en.m.wikipedia.org/wiki/File:Animated_gun_turret.gif It's a 7.7 second looping gif, so it violates the current MOS rules as well as my suggestions. 173.73.0.102 (talk) 22:09, 12 March 2023 (UTC)
It looks like that has been cleared up. I started writing a warning for FormalDude but leaving it might work. Let me know if more problems arise. Johnuniq (talk) 06:59, 22 March 2023 (UTC)
On my first encounter with this page, I got completely confused with long strings of favoured and deprecated code, often code with which I'm unfamiliar ( {{templates|}}, etc. )
Sites like Help:Tables often show the "printed" results (i.e. what would normally appear on regular screens) of using either correct or incorrect code and Wiki-markup.
Unless it completely frustrates those using screen readers, would it be possible to illustrate the appearance produced by correct and incorrect markup and codes? —— Shakescene (talk) 18:01, 3 April 2023 (UTC)
As a screen reader user, I wouldn't have a problem with this in general but I wouldn't know how to format it well enough. However, you'll need to be more specific about which passages need more examples. One problem with this page is that sometimes favoured and undeprecated markup *looks* the same to users without disabilities but is semantically different. Graham87 14:09, 4 April 2023 (UTC)
You are invited to join the discussion at Wikipedia talk:WikiProject Templates#Images in templates about how to handle templates that were created to insert images of typographic characters. These characters are now available via Unicode. Please comment there if interested, Rjjiii (talk) 01:54, 5 June 2023 (UTC)
Suggest a removal
Hello, I suggest removal or alteration of the below paragraph. Before anyone gets all up in arms about it, I'll clarify that it is misleading and not applicable anymore.
On 14 January 2006, the Board of the Wikimedia Foundation passed the following nondiscrimination resolution: "The Wikimedia Foundation prohibits discrimination against current or prospective users and employees on the basis of race, color, gender, religion, national origin, age, disability, sexual orientation, or any other legally protected characteristics. The Wikimedia Foundation commits to the principle of equal opportunity, especially in all aspects of employee relations, including employment, salary administration, employee development, promotion, and transfer". The WMF asserts that its policies "may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project".
The resolution text is accurate, but the resolution was to create a policy, linked here, which was edited by the WMF in 2017 to remove any responsibility over users. Thus, the policy has not applied to Manual of Style/Accessibility in 5 years. I would suggest we replace it with the text of Policy:Universal Code of Conduct, and perhaps someone should suggest that the WMF's nondiscrimination policy be updated to be cohesive with the UCOC. ɱ(talk) 14:16, 1 June 2023 (UTC)
Wow, interesting re Nupedia ... but I shouldn't be surprised (see the user page of an early editor, RoseParks). I wonder how much practical effect these early efforts had, considering Nupedia/Wikipedia's already text-based nature. As someone who's been monitoring this page almost since its inception in its current form, I'm not sure what I think of writing out a full history of the accessibility guidelines ... it would dredge up many old disputes and a lot of the people involved in the past aren't here to speak up for themselves now. I'd rather the outdated text be removed. Graham87 02:33, 11 June 2023 (UTC)
Not full story, short timeline? Nupedia - … - Universal Code. Do you want to remove this entirely? Proeksad (talk) 10:24, 11 June 2023 (UTC)
Yeah I've gone and done it. The history of discussions about this page and accessibility on the English Wikipedia is contained within the archives here and those at Wikipedia talk:WikiProject Accessibility. I'm usually an avid wiki-historian, but I think that's enough here in this case. Graham87 15:43, 11 June 2023 (UTC)
OK. On the other hand, not so formal and bureaucratic Proeksad (talk) 16:12, 11 June 2023 (UTC)
Here is a proposal to change text within the guideline rather than outright removing it:
First, change the lines Screen readers have widely varying support for characters outside Latin-1 and Windows-1252 and it is not safe to assume how any given character in these ranges will be pronounced. If they are not recognized by the screen reader or speech synthesizer, they may be pronounced as a question mark or omitted entirely from the speech output. to instead read: Screen readers have widely varying support for obscure characters and it is not safe to assume how they will be pronounced. If they are not recognized by the screen reader or speech synthesizer, they may be pronounced as a question mark or omitted entirely from the speech output.
The reason is that based on the discussions that generated this advice and later testing, it seems there are characters within those two ranges that are still not safe to assume will be read. The advice, especially with a link to the ranges, can be misleading. Rjjiii (talk) 07:15, 30 June 2023 (UTC)
I don't know about that ... "obscure characters" is vague. Obscure to whom? Maybe "obscure characters in English" or something. The latest discussion about this guideline is this section. By testing I assume you're referring to this page and recent discussions (and your user subpage about this subject). Also, all the major screen readers listed on the external link (JAWS/NVDA/Voiceover) will indeed read almost all symbols in Windows-1252/Latin-1 given a high enough punctuation level (only the default one is used in that link, and good screen reader users should know how to adjust it). The only exception I know of is , which should almost never be used in articles. I don't really want to collapse the net of safe characters because it will just lead to more bickering that will mostly be useless. Graham87 15:58, 30 June 2023 (UTC)
And the Soft hyphen can be interesting too ... Graham87 16:22, 30 June 2023 (UTC)
That makes sense and I'll leave that section as is. The linked user subpage is a rough draft of the documentation for templates like {{section-sign}}, {{hash-tag}}, and {{dagger}} that previously generated an image with alt text and now generate a Unicode character.Rjjiii (talk) 01:19, 1 July 2023 (UTC)
Yes you can. I've tweaked them to use "<br />" though. Graham87 15:13, 15 July 2023 (UTC)
I revisited issue, producers list is merely repetition of infobox info. Either i delete whole section or use hlist or flatlist..... రుద్రుడు చెచ్క్వికి (talk) 17:54, 15 July 2023 (UTC)
Can we deprecate the advice on typographic symbols?
Per the linked discussion above, I've upgraded several templates including Template:dagger with the kind assistance of several editors. These templates previously used low-resolution image files with alt text. This inhibits searching, copying, and pasting. The templates now use the Unicode symbol with an aria image role to maintain backward compatibility with the custom alt text.
When reaching out to people who use screen readers, several noted that using alt text in this way makes it impossible to adjust the settings of the screen reader to ignore symbols. One member of the NVDA users' mailing list observed that the way many Wikipedia articles use typographic symbols like asterisk, dagger, and double-dagger is an unnecessary emulation of printed footnotes, considering that Wikipedia has multiple hyperlinked footnote systems. I didn't convert the templates into substitution-only typing aids partly because it seems the Manual of Style recommends this usage, but I think that's eventually where they should go.
I think the following passages should be clipped from this page:
; use images with alt text instead.
Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
Abbreviations are exempt from these requirements, so the template (a wrapper for the <abbr> element) may be used to indicate the long form of an abbreviation (including an acronym or initialism).
I am no expert on this though, so I wanted to leave this open for discussion here. Feel free to provide feedback, questions, disagreement, or much better ideas. Regards, Rjjiii (talk) 09:02, 22 June 2023 (UTC)
...many Wikipedia articles use typographic symbols like asterisk, dagger, and double-dagger is an unnecessary emulation of printed footnotes, considering that Wikipedia has multiple hyperlinked footnote systems: A lot of tables use a legend, and not footnotes, consistent with MOS:COLOR (emphasis added):
Especially, do not use colored text or background unless its status is also indicated using another method, such as an accessible symbol matched to a legend, or footnote labels
@Rjjiii, I think it might help me if you could link to a couple of articles that you'd like to see changed. Template:Dagger is used ~1300 templates (e.g., in the navbox Template:William Shakespeare), and this non-mainspace/transcluded use seems to account for two-thirds of the uses. WhatamIdoing (talk) 20:28, 20 July 2023 (UTC)
@Rjjiii, Also not an expert here, but what I'm wondering is whether hearing "dagger" in some instances is the best result. While Wikipedia does have an extensive footnote system (which I freely admit I don't understand), if a symbol appears many times in a table or template to indicate a specific meaning, it might be better to hear a brief version of that meaning than to have to jump to the footnote many times to get that meaning. I was going to propose updating {{Lists of flags}} to use a safe symbol to indicate non-sovereignty rather than just italics...
but rather than hearing "Australia link, state governors link dagger, Christmas Island link dagger, Cocos (Keeling) Islands link dagger, Norfolk Island link dagger"
or worse "Australia link, state governors link d link, Christmas Island link d link, Cocos (Keeling) Islands link d link, Norfolk Island link d link" where "d" is a link to footnote d
it might be better to hear "Australia link, state governors link non-sovereign, Christmas Island link non-sovereign, Cocos (Keeling) Islands link non-sovereign, Norfolk Island link non-sovereign"
which would require a change to the coding for {{dagger}} to allow for a title parameter. Thisisnotatest (talk) 04:21, 28 July 2023 (UTC)
Template:Dagger emits just the dagger (†) Unicode character. This is read as "dagger" or "single-dagger" on screen readers if the character is within the user's verbosity settings. Rjjiii (talk) 04:49, 28 July 2023 (UTC)
How about {{dagger|1=Insufficient sample size}} to yield <span aria-label="Insufficient sample size">†</span>? Or even <span aria-label="Insufficient sample size" title="Insufficient sample size">†</span> so that users of pointing devices can benefit from the tooltip on hover? Or the dagger and the ARIA text can go in separate spans, the former to be hidden from screen readers and the latter an empty span with the aria-label, so that when alternative text is provided, the reader doesn't have to also hear "dagger". Largoplazo (talk) 11:28, 28 July 2023 (UTC)
That doesn't work in either of my Windows screen readers and doesn't seem to be what that tag is for. As a screen reader user, I'd say if sighted people are seeing a dagger symbol, blind people should hear "dagger" (or read it in Braille) as well. Graham87 14:45, 28 July 2023 (UTC)
Italics issues
I came here because I notice that {{Lists_of_flags}} is dependent on italics for meaning and wanted to get some clarification on Wikipedia accessibility style before I either posted to that template's talk page or went ahead with an edit.
I notice the following on this current page: "it is preferable to use Wiki-markup '' or ''' for purely typographic italicization and boldfacing,". However, that template is using two apostrophes to italicize, and if I inspect the code, I see the <i> tag, not the expected <em> tag. Has the rendering of Wikicode been changed?
Further, specifically with respect to the template, is using italics for meaning (in the case of {{Lists_of_flags}}) to represent non-sovereign entities "purely typographic"? While screen readers theoretically can read emphasized text, various sources I'm reading claim it isn't the default. Unfortunately, I'm not able to find an authoritative source and don't want to act on "everyone knows" type information.
But if it's true, people using screen readers are not being informed by this template as to whether particular entities listed in that template are sovereign. Special characters are also reported as potentially problematic, so a substitute character might be hard to fine.
Knowledge? References? Thoughts?
We might need edits both to the template or to the current page or to report a Wikicode issue, or all three.
I think it's OK because it specifies the meaning of the italic text so screen reader users can either check if an entry is italic or turn italic indication on temporarily if need be. Yes, most screen readers don't indicate bold/italics by default. Graham87 14:36, 28 July 2023 (UTC)
It might be acceptable, but it somehow doesn't feel like the best we could do. WhatamIdoing (talk) 16:51, 28 July 2023 (UTC)
Looking at WP:LISTGAP, I wonder why they don't change the software so that whitespace between bulleted items is ignored instead of being treated as a list break. I imagine there must be a scenario where treatment as a list break is desired, but I'm not coming up with such a scenario myself. Largoplazo (talk) 11:17, 26 July 2023 (UTC)
What if you want two subsequent lists ? there's no difference between those two situations in wikitext. So how would you magically identify the one from the other ? —TheDJ (talk • contribs) 11:29, 26 July 2023 (UTC)
(I closed up your own WP:LISTGAP.) Who creates two subsequent lists? I already said I imagine there must be a scenario where treatment as a list break is desired. Your response is basically a repetition of that, as you didn't provide a scenario. Who, for example, creates something that looks like
Blue
Green
Orange
Yellow
and wants them to be understood to be two lists, expecting that readers will recognize them as such rather than as one list with a spacing glitch? Normally lists have lead-ins:
These are my sister's favorite colors:
Blue
Green
These are my brother's favorite colors:
Orange
Yellow
I'm looking for a realistic scenario. Otherwise, the choice is being made to stick with a situation where only the very few people who've read WP:LISTGAP are going to know not to add blank lines between bulleted items, causing accessibility problems, and to reject a solution that would eliminate that problem altogether on the grounds of a technical problem that is, in practice, nonexistent. (Yes, I see how the gap in the first example breaks up the list of this discussion. Don't know what to do about that.) Largoplazo (talk) 12:34, 26 July 2023 (UTC)
To embed multiple bulleted sublists into one list item, the {{bulleted list}} template can be used. The resulting space between bulleted list items is, however, slightly smaller than in your example, because the closing of the two nested unbulleted lists adds a bit of extra vertical space.
car
truck
van
airplane
bus
train
I have, on my userspace pages, used consecutive bulleted lists to create implicit sublists without specifying a specific theme for each. (You may be able to deduce some themes in this example.)
With regard to current practicalities: altering the wikitext parser to treat empty lines between list items differently would require investigating all current uses and checking if they need to be changed. Also, since lists are, for better or worse, used for threaded conversation on talk pages, I think there are editors who will continue to want to break up discussions under some circumstances, and thus there would be a large education process required to let editors know what new syntax would be required to do this. In short, the legacy uses and transition to new syntax would pose challenges for acceptance by the community. isaacl (talk) 05:32, 28 July 2023 (UTC)
Incidentally, I have the following code in my common.css style sheet to make list gaps visible with a wide grey dashed line:
Perhaps a partial solution would be css in the site wide stylesheet that makes the gap more prominent but not completely unacceptable, like a 2 or 3-em margin. —MichaelZ. 16:26, 26 July 2023 (UTC)
There is a slight spacing difference, and that is enough for me to be able to see them. Also, I think there is (or was) a bot that removes list gaps in articles.
BTW, @Largoplazo, having a single blank line before or after a list causes no problems at all. The transition through "paragraph list paragraph" is parsed identically regardless of whether or not there is a blank line in the wikitext. WhatamIdoing (talk) 16:50, 28 July 2023 (UTC)
On French Wikipedia, colon-indented discussion threads have a nice system of borders and alternately-tinted backgrounds that (I believe) are intended to make it easy to work out which post is being replied to, when the reply is two screens later on. Here's the essential part of the stylesheet for Vector-Legacy & Vector-2022:
The borders are displayed to any depth of indentation, but the alternation of background tints stops after 13 colons (9 in Modern and MonoBook). The tinted backgrounds are shown to best advantage in Modern skin, where the borders and background tints are grey; they are blue in both versions of Vector, and yellow in MonoBook. However, in Timeless the background isn't tinted and only the top borders are shown (as a dotted line), and in both Cologne Blue and Minerva Neue skins there are neither tints nor borders shown.
These borders have a bonus that they also make it easy to pick out instances of LISTGAP. See e.g. this post at fr:Discussion:Paris, where the two posts that follow display two different issues:
At the bottom of the post of 12 mai 2022 à 00:06 (CEST), the three left borders all terminate, and then four new borders precede the post of 12 mai 2022 à 00:42 (CEST): this reveals the presence of a blank line in the wikitext
Between the post of 12 mai 2022 à 00:42 (CEST) and that of 12 mai 2022 à 10:56 (CEST), there are two new borders instead of a single one: this reveals the presence of an extra colon in the indenting
Have we ever considered something similar for English Wikipedia? --Redrose64 🌹 (talk) 20:00, 29 July 2023 (UTC)
I have never seen a sustained conversation on adopting this. I suspect that the place to begin would be writing a gadget, so people could try it out before considering a sitewide change. Editing had talked about a less obvious version (e.g., a pale gray line just on the side) a year or two ago, and I'm sure that @PPelberg (WMF) would doubtless appreciate a ping if you wanted to start a discussion about it at VPT. (Hi, Peter! One more week of vacation. See you soon.) WhatamIdoing (talk) 21:04, 6 August 2023 (UTC)
I created my own version to experiment with. If you use a recent version of Safari or a Chromium-based browser such as Chrome or Edge, and are interested in trying it out, see User:Isaacl/style/discussion-threads. It's subject to change as I try different things. It supports nested lists of any combination of bulleted and unbulleted lists (up to 18 levels), but the current styling for bulleted lists is awkward. It works on any page for which the reply tool has been enabled (as it checks for an HTML attribute used by the tool). isaacl (talk) 22:26, 9 August 2023 (UTC)
The solution used at WP:UAA is a blank line with just an asterisk, which renders as whitespace.
blue
green
yellow
orange
Like that. I assume that would work anywhere. Beeblebrox (talk) 01:07, 10 August 2023 (UTC)
Empty list items are hidden and thus not announced by screen readers. (They aren't rendered as additional whitespace, as far as I can tell and recall from previous discussion.) It's a technique to add vertical space in the wikitext source that doesn't affect the visible output or the output from screen readers. To do this with nested lists, you need to replicate the entire prefix to avoid ending/starting new lists:
:*blue
:*green
:*:*yellow
:*orange
Your example above has extra whitespace because it closes two nested lists, opens a first level list which has no visible items, closes it and then opens two nested lists again:
:*blue
:*green
*:*yellow
:*orange
I'm not sure if screen readers will still announce the empty list; I'm guessing they do, because it is still rendered (it adds the extra whitespace). But I'm pretty sure it will cause screen readers to announce the closure of the first two nested lists and the starting of the second two nested lists. So I don't think this solves the problem posed by the original poster. I agree that replicating the entire prefix will help with adding vertical space in the source, but I don't think that can be used as an automatic software-applied solution, which the original poster was seeking. isaacl (talk) 02:02, 10 August 2023 (UTC)
blue
green
yellow
orange
Neither of the two main Windows screen readers announce empty lists. Also, replicating the entire prefix does indeed work and doesn't get announced at all. Graham87 09:01, 10 August 2023 (UTC)
In your example, there isn't an empty list, but an empty list item within the highest level nested list. Is there an announcement for the following empty list, and is there one announcement for the blue-green list and another for the yellow-orange list?
There's no announcement of the empty list but the lists of two items are announced separately. This is true of JAWS; I'll report later if NVDA is any different. Graham87 04:44, 11 August 2023 (UTC)
I am looking at the list formatting in Wikipedia:WikiSpeak, and wondering whether there is a better way to organize it. The problem is that we have multiple "definitions" for some terms, and that this is not easy to see. So: add numbers? add bullet points? change sitewide CSS to make it easier to see? something else? WhatamIdoing (talk) 15:52, 13 September 2023 (UTC)
See MOS:GLOSSARIES for how to handle rich formatting of description/definition/association lists (what resolves to <dl>, <dt>, <dd> markup). — SMcCandlish☏¢ 😼 23:47, 13 September 2023 (UTC)
I am mediating a content dispute at DRN concerning the display of the scores of football. One of the issues is that one of the editors states that some of the templates that are being used to display club seasons does not comply with the accessibility guidelines. Here is how I am asking for assistance from this project. I would like to request an experienced editor to look at the dispute, and either say that some of the templates that we are using are not access-compliant, or that the templates that we are using do satisfy the accessibility guidelines. The editors with the accessibility issue can come to this project page and present their cases, or it would be useful if an experienced editor who is familiar with accessibility joined in the discussion at DRN. There seems to be a lot of anger by some of the editors. Thank you in advance for any help you can give. Robert McClenon (talk) 16:34, 22 September 2023 (UTC)
use of bold for pseudo-headings
The guidance at MOS:PSEUDOHEAD includes: "Do not make pseudo-headings by abusing semicolon markup (reserved for description lists) and try to avoid using bold markup." The example immediately thereafter uses bold markup in the "acceptable" version. I'm not sure what to make of that. At what point has an editor tried hard enough, and bold markup is acceptable? Is there any consensus on this? ~TPW 13:28, 21 September 2023 (UTC)
It does say bold pseudo-headings are discouraged but acceptable, and may be useful to keep sub-sub-subheadings out of the TOC in only some parts of the article (i.e. when {{TOC limit}} can’t be used). (Seems dubious to me, but that’s what it is.) Maybe needs clarification. —MichaelZ. 18:28, 21 September 2023 (UTC)
Thanks. This concept is new to me, and any details are helpful. I became aware of it through this edit, but there the preference appears to be to use bold for pseudo-headings after a section header, not a sub-header. I admit that I'm thoroughly confused as to what an editor is supposed to do. ~TPW 18:33, 21 September 2023 (UTC)
Use nested sub-headings (and sub-sub-headings and so on), unless there's some really compelling reason to use a pseudo-heading, and even then don't abuse MOS:DLIST markup to do it. — SMcCandlish☏¢ 😼 00:43, 22 September 2023 (UTC)
I appreciate your insight. Is it only your own, or is it drawn from some consensus on how to apply MOS:PSEUDOHEAD? I'm utterly perplexed. ~TPW 13:45, 22 September 2023 (UTC)
I'm literally just summarizing the guideline for you. It's not an "insight" on my part, and the fact that it's a guideline indicates it is a product of consensus. — SMcCandlish☏¢ 😼 19:13, 22 September 2023 (UTC)
I wouldn't even know how to request comment, because I don't know what's intended by that manual entry at all. ~TPW 13:46, 22 September 2023 (UTC)
TPW, I don't know if you've ever tested a page with a screen reader, but if not: you can use the keyboard or touch-screen gestures to navigate the page via the tree created by the headings. This is the most commonly preferred way to navigate long documents on the web: https://webaim.org/projects/screenreadersurvey7/#findingRjjiii(talk) 05:06, 22 September 2023 (UTC)
Thanks. If that was intended to answer my question about when to use bold markup, I'm afraid I'll need you to restate it as I don't understand. ~TPW 13:42, 22 September 2023 (UTC)
To restate, then: Use nested sub-headings (and sub-sub-headings and so on), unless there's some really compelling reason to use a pseudo-heading, and even then don't abuse MOS:DLIST markup to do it. Doing otherwise introduces accessibility problems for users of screen-readers (among other issues that can result). — SMcCandlish☏¢ 😼 19:13, 22 September 2023 (UTC)
Obviously not all of this information is pertinent or appropriate for an encyclopædia, but I think the core advice of
We use numerals for numbers (including 1 and 2), for example when we're talking about statistics, time, measurements, lists, points or steps. People find numerals easier to read and they scan for them.
For numbers over 999, use a comma for clarity – for example, 1,000.
is probably good advice for us too — especially given that, as well as people who struggle with numbers, we will have a lot of users who are not first-language English. Changing uses of fourteenth century to 14th century and five years earlier to 5 years earlier, for example, would make us substantially easier to parse and read for many users. — OwenBlacker (he/him; Talk) 11:04, 26 September 2023 (UTC)
We already use "14th century", per the rule to use numerals for numbers 10 and higher (MOS:NUMERALS, MOS:ORDINALS). But yes, we do still write "eighth century". I think you'd get a whole lot of resistance to us changing to write things like "She was a 5-time world champion at [sport name]" or "His 1st novel was published in 1987". It defies pretty much every English-language style guide ever published, looks informal/sloppy to many readers (despite being ultimately pretty inconsistent), and it would result in beginnining many, many sentences without a capital letter ("3 people were killed in the collision."), as well as introduce confusion about how to handle derived terms ("2ndary"??).I'll repeat what I always say to propositions like this. Wikipedia is not beholden to some external publisher's ideas, no matter how impassioned they (and some editors) are about them. And Wikipedia is not a vehicle for language-reform activities; we never "lead the way" in changing English usage, and only adopt new-fangled usages when most of the style guides MoS is actually based on have adopted the change, and there is overwhelming proof that the change has been accepted across contemporary professional English-language writing in general. We of course care about accessibility, and go to much further lengths than is typical for other publications and projects, but we cannot practicably address every alleged accessibility concern ever raised by anyone, especially when one of them comes into conflict with other concerns (most do not, e.g. there is no conflict caused by, say, avoiding list-gaps in our markup, or providing alt text for images; it's just a little more work for editors). But this idea would directly result in a lot of our readers mentally going to "revolt" at our writing.This ultimately is essentially the same debate as "Wikipedia should stop using 'committed suicide' because various external publishers advocate dropping it", and "Wikipedia should use singular-they as a generic gender-neutral pronoun because various external publishers adovcate for it". In the end, we just ignore the advocacy and look at actual usage and at major sources on academic-register English usage in the aggregate. The results have been that WP has adopted singular-they because English usage has adopted it, and we have not yet adopted a rule against the phrase "committed suicide" because mainstream English usage has not yet abandoned it. To come full circle: mainstream English has not abandoned writing "three", and seems unlikely to do so, any time soon, though we'll of course pay attention to actual usage patterns and the recommendations of the style guides that matter for our kind of writing, as the years march on. PS: I write all this as someone with mild discalculia myself. I'm extremely skeptical of all adovocacy-minded prositions to change WP policies and guidelines, not just those that don't relate to me personally. — SMcCandlish☏¢ 😼 12:25, 26 September 2023 (UTC)
I was unable to find a talk page discussion about that change. Here's the relevant RFC. Also note the hidden comment in that section about matching text on another MOS page, which was no longer matching after the wording change. I have made them match again. – Jonesey95 (talk) 04:12, 30 September 2023 (UTC)
There has a long been a MediaWiki feature for partial transclusion, of just a section of a page, and this is the sort of thing it is intended for. HTML comments or not, don't expect material copied from one page to remain unchanged in another. — SMcCandlish☏¢ 😼 07:11, 30 September 2023 (UTC)
Left-hand images
Avoid placing images on the left hand side as a consistent left margin makes reading easier.
This guidance seems to go much further than the guidance at Wikipedia:Manual of Style/Images § Location. I would suggest rewriting it to be consistent with that. Cheers, {{u|Sdkb}}talk 04:09, 23 March 2023 (UTC)
Especially when there is guidance at MOS:PORTRAIT to have portraits of people look into the text, which would place some images on the left. I've seen some edits merely cite MOS:ACCIM in the edit summary of such images, and moving them from the left to the right. Either clarifications are needed at MOS:ACCIM, or consensus is needed on harmonizing conflicting MOS points. —Bagumba (talk) 04:26, 1 June 2023 (UTC)
Appears one editor snuck in this text last July, without any discussion. Reverted as contrary to existing MOS and without discussion (guidelines like this ought to be page-protected to prevent this). It's constantly been part of a nitpicky campaign, and is just an extreme dislike for some users. There's no foundation in the idea that it has any accessibility problems, and it's been a norm and part of MOS likely since Wikipedia was founded. ɱ(talk) 05:15, 1 June 2023 (UTC)
Yes, remove or at least soften. The old (ancient) instruction used to be to alternate left and right hand images, but with the multiplication of types of devices and screen sizes this ceased to make much sense. But "Avoid placing images on the left hand side" is way too strong. Johnbod (talk) 14:39, 1 June 2023 (UTC)
We used to say not to put images on the left immediately under a ===Level 3=== subsection (or greater) heading. (The idea was that the light gray line on the ==Level 2s== helped draw the eye towards the first word, but no such line exists in the other section heading levels.) That was probably removed about 10 years ago.
Alternating left and right is unusual, except for articles with lots of images (e.g., Wedding dress) and FAs. WhatamIdoing (talk) 17:37, 15 June 2023 (UTC)
I thought not putting left-aligned images the first thing under heading (and hatnotes) was still the norm. I believe that section content should start with text, and that images should not be staggered left-right-left, but right-left-right. I have never had a reading disability or vision problems, but when a section starts with an image, and I want to skim through the text of the whole article, the left-aligned image, especially with a caption (my eyes are pulled toward reading the first-thing-on-the-left caption text ... when the text that I want to read is not that but article prose) is definitely making it harder for me. Also, the image then comes before text and is not immediately very useful as illustration. I have to first be distracted by the image, say "meh, I'll come back to it maybe, when I read the actual article content that I want to read" and then actively go back to look at the image. It's almost always a more fluid reading experience when the image is right-aligned. The only time when it's totally okay for me for an image to be left-aligned is when it's not the first thing under the heading+hatnotes and when the image is attached to the paragraph below the content that it actually illustrates, so it comes after text; this is however very rarely achievable.—Alalch E. 00:57, 17 July 2023 (UTC)
I think that when people post a left-aligned image at the start of a section, it's the only image in that section.
That might not be clear, so let me give an example:
Early education
Swing (example)
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Film career
Film icon
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Personal life
Icon people
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
This will look different on different people's screens, but there isn't any "left-right-left" within a section, because there is only one image in each section. Also, note how the images overflow into the subsequent sections. If people are starting the first section with a left-aligned image, it might be because the infobox or lead image flows down the page. WhatamIdoing (talk) 02:24, 17 July 2023 (UTC)
This discussion has essentially moved to #Right hand images continued, below. Adding more replies to the thread above may go unnoticed. — SMcCandlish☏¢ 😼 19:31, 3 October 2023 (UTC)
Right hand images continued
Hi. I found an unilateral inclusion here by Moxy who I usually agree with. But this is a bit contentious. @Moxy: can you or anyone please explain the rationale for easier reading? How would a screen reader do better with right aligned images? 6. Avoid placing images on the left hand side as a consistent left margin makes reading easier. See MOS:IMAGELOC Thank you. I'm in the middle of a FAR and would like to conform to both accessibility guidelines and MOS. The FA I'm working on has had right-left images since 2007 and before. They went unchallenged until now, where MOS enforcement by Magnolia677 seems to be a matter of opinion. SusanLesch (talk) 15:14, 3 October 2023 (UTC)
@SusanLesch: The image alignment at Minneapolishas not been "unchallenged until now".
In 2017, I right-aligned an image here; you challenged my edit here.
In 2022, I right-aligned images here; you challenged my edit here.
You then participated in this discussion about the image location on that article. Magnolia677 (talk) 18:03, 3 October 2023 (UTC)
Thank you! I searched for and failed to find that discussion. It left us with the status quo, and didn't change a thing. My question here remains, the answer to which could change everything. Why is right alignment of images better for screen readers? -SusanLesch (talk) 18:12, 3 October 2023 (UTC)
Maybe put in a bit more research before writing negative comments about others. Magnolia677 (talk) 22:37, 3 October 2023 (UTC)
It’s not. But neither did anyone here claim that the reason was for screenreaders. If you think that accessibility is only about screenreaders, then please read up on the topic a bit. The claim is that having the indentation level of the text jump around, especially at the left side, where you have to start reading, makes the process of reading more difficult. This is true even for people without any disability whatsoever, but definitely applies even more in those cases.
Having said that, Wikipedians have a tendency of overindulging and over enforcing most rules and/or lack of rules. Having images on the left side is not forbidden, not even in FA articles. It’s an editorial choice that should be made carefully, weighing the pros and cons after informing yourselves. —TheDJ (talk • contribs) 19:00, 3 October 2023 (UTC)
There used to be an overindulging of placing too many images in an article by making use of both left and right side of the article, often even alternating between the sides. This was bad. A better solution is to use a horizontal gallery in those cases.
if ppl use this guideline to eradicate all left placed images from all articles, that would also be bad. —TheDJ (talk • contribs) 19:08, 3 October 2023 (UTC)
Left-aligned images aren't a problem adjacent to plain text; the problem is when they are alongside lists, because the list won't be indented as expected; which is a problem for partially-sighted readers. --Redrose64 🌹 (talk) 19:18, 3 October 2023 (UTC)
Right. ("Agreed" I mean, not "on the right-hand side".) There's some kinda-polemic stuff above claiming that any use of left-aligned images is some kind of general readability-accessibility problem for everyone, but this does not appear to be the general consensus here, or we would not have advice on how to left-align images, and advice that suggests staggering images to avoid a huge stack of them on the right. — SMcCandlish☏¢ 😼 19:23, 3 October 2023 (UTC)
Thank you Moxy, and everyone. We'll try flush right images for a while. -SusanLesch (talk) 22:04, 3 October 2023 (UTC)
I for one won't. The complex and well-illustrated articles I'm spending most of my time here on would turn into total trainwrecks with all the images moved to the right (or lose quite valuable illustration by removing a bunch of them to compensate). — SMcCandlish☏¢ 😼 23:13, 3 October 2023 (UTC)
Looking at the edit history, Moxyattempted in July 2022 to unilaterally add guidance here that went beyond the existing guidance at MOS:IMAGELOC, using the at-best-undescriptive edit summary "ce". When myself and other editors noticed this change in March (see above), we formed a consensus to revert it, which Ɱdid. Moxy did not participate in that discussion, but then re-added the change in July using the just-as-opaque edit summary "ce link up". That has now been noticed again.
In Moxy's defense, they were not pinged in the March discussion, so I will assume good faith that they just missed it. But I am reverting the change to restore the status quo, since substantive changes to guideline pages should have affirmative consensus and should not contradict other guidelines. I remind Moxy that all editors are expected to use good communication practices, including descriptive edit summaries, particularly when editing pages like guidelines, and that edits to guidance pages require extra care as cautioned in the editnotice. If the change is made again without consensus (either here or at MOS:IMAGELOC) then it will be a behavioral issue. {{u|Sdkb}}talk 22:54, 3 October 2023 (UTC)
I'm in agreement with this summary. — SMcCandlish☏¢ 😼 23:13, 3 October 2023 (UTC)
No clue there was a talk...but sounds good not all the edits i do to our protocols will be liked by all thus why we have chats. This was just a basic readability norm for legibility harvard......thus did not think anyone would not agree. But If others think the wording impedes on their preferred style best we stick with original MOS wording that leaves this more open.. disability access is a hard one. Moxy- 23:57, 3 October 2023 (UTC)
But this "issue" doesn't seem to be grounded in "disability access", but a broad claim that exclusively right-side images are more readable for everyone, generally. In one extremely limited sense, that might actually be true, kind of like it's technically true that people can read very short Hemmingway-style sentences more easily, or that an outline is faster and easier to parse that even short paragraphs of prose. But that doesn't make it the best way to present information encyclopedically. If someone needs such an approach badly, they can try Simple English Wikipedia. In making this site, we have a tacit agreement that some forms of complexity will be involved, because they make the content overall better, and serve the core purposes of the site better, for the readership at large, without pointedly disadvantaging a class, especially in ways that can be avoided at no real cost (like adding alt text or avoiding list-gaps). But doing nothing but right-side images is actually a high cost, in multiple ways, for a benefit that is dubious at best. — SMcCandlish☏¢ 😼 00:16, 4 October 2023 (UTC)
All we can do is strive to make accessibility better for all our readers. This will sometimes conflict with preferred layouts. But is this a big accessibility concern ....not really. Thus I have no problem with its removal. What we need to work on is info box accessibility. Moxy- 00:40, 4 October 2023 (UTC)
To be clear, Magnolia677, your MOS needling accomplished nothing. But it got me to this talk page, so thank you.
TheDJ changed my 15-year-old habit of right-left. They right-sized the accessibility project, and gave me a good reason: optimize the process of reading. Now I remember, Text Is King. I agree 100% with SMcCandlish there is no reason or consensus in MOS to require right alignment. -SusanLesch (talk) 14:41, 4 October 2023 (UTC)
Its been in the main MOS for over a decade....but again... do what is best in each case. Moxy- 19:43, 4 October 2023 (UTC)
Understood. Thank you! -SusanLesch (talk) 21:25, 4 October 2023 (UTC)
Please see Talk:Singular they#MOS:DLIST. The short version is that the article is abusing : (= HTML <dd>) description/definition/association list markup dozens of times as a visual indentation mechanism, and needs cleanup to use {{block indent}} or (where actual quotations are used) {{blockquote}}. And, where DLISTs are appropriate, it should be using proper ; with : lists, not mangled * with : markup. But I'm not finding I have the time and patience to do it all. — SMcCandlish☏¢ 😼 11:10, 28 October 2023 (UTC)
Never in my decade plus on Wikipedia have I encountered such a monstrosity
Making redundant table captions screen-reader-only
I know it's most important that table captions be present in the first place rather than necessarily visible to sighted readers, but the user User:Nkon21 has over the past several days been making all captions in the topic area they edit in of K-pop releases screen reader-only, despite this appearing to be a cosmetic change done solely for their own benefit/the benefit of sighted readers, when no other editor as far as I can see has had an issue with the captions being visible since they were introduced, let alone anybody expressing that their presence to sighted readers is a hindrance or an inconvenience. The user has repeatedly linked to Template:Screen reader-only, which states it "should only be used to hide text from sighted readers when that text substantially duplicates adjacent text that is visible" despite Wikipedia talk:Manual of Style/Accessibility/Archive 15#RfC on table captions concluding in 2020, around the same time this template was created, that captions should still be present (and therefore visible) even if considered redundant to sighted readers. For the record, this is primarily concerning making captions like "Chart performance for [song]" under headings like "Charts" screen reader-only, e.g. [2]. Thoughts on this? Ss112 00:58, 26 November 2023 (UTC)
I have no knowledge of precedent but the effect of adding {{sronly}} at Butter (song)#Weekly charts was to replace the somewhat silly dual headings such as Weekly charts / Weekly chart performance for "Butter" with just Weekly charts. I can see the point of Nkon21's edit. Johnuniq (talk) 01:48, 26 November 2023 (UTC)
@Johnuniq: I know why the edits were made, but adding visible captions to all tables has been done for years and nobody has raised a real concern in the years since that this repetition is somehow inconveniencing sighted readers and we should or now need to start hiding the captions with sr-only. The RfC at this very talk page in 2020 determined, even when editors in that discussion pointed out that the captions are repeating what's already known because of the headings, that they should always be included, with no great argument in favour of hiding them from sighted readers with sr-only. Ss112 02:57, 26 November 2023 (UTC)
Accessibility guidelines states that The caption element is the appropriate markup for such text and it ensures that the table identifier remains associated with the table, including visually (by default). In addition, using the caption element allows screen reading software to navigate directly to the caption for a table if one is present. 1) Captions are designed to distinguish table content from already existing text, but all of these captions are substantially the same as existing headers other than simply adding the subject of the article at the end of it, which adds basically no new value for readers. 2) Captions are a necessity in terms of accessibility for screen readers to navigate directly to the table. The RfC User:Ss112 linked had most of its support based on accessibility for screen reader software to function better, but using Template:Sronly makes that not a problem and there was no argument that was made against the use of it. So all in all, what are the point of captions? If they serve no purpose being visible than hiding them shouldn't be an issue. ɴᴋᴏɴ21❯❯❯talk 03:46, 26 November 2023 (UTC)
@Nkon21: I'm not going to argue with you here about this, as I want the input of other editors more experienced in formatting matters, but this is coming out of nowhere. Nobody has raised a large concern about the apparent inconvenience of having repeated text in captions in the three years since they became a requirement; they've accepted them as a necessary part of having table formatting. (Not that MOS:DTT is exhaustive, but the how-to also makes no point to say readers can or should opt out of captions visible to sighted readers with the use of Template:Screen reader-only.) Some of the K-pop articles you hid captions from sighted readers on did not even have captions on some tables, which I had to insert, so it appears you don't necessarily care about ensuring that they're present for those who use screen readers, you would just prefer sighted readers and yourself not have to see the ones that are present, so I reverted those edits primarily because this appears to be about cosmetic appearance, not necessarily redundancy. As I pointed out, the 2020 RfC concluded that even if captions are repeating text that sighted readers know from the headings, they are still a necessary part of table formatting. I don't feel "but captions are repeating context from the headings" would have been raised as a concern and then "but they're still necessary" would have been concluded if we should just hide the captions from sighted readers. Ss112 05:36, 26 November 2023 (UTC)
Perhaps this discussion should focus on exactly what "Data tables should always include a caption" means at Wikipedia:Manual of Style/Accessibility#Data tables. The RfC linked in the OP clearly intended the caption to be a requirement for screen readers and I don't know what discussions have occurred regarding visible captions. At any rate, Nkon21 should definitely not continue making changes until this is resolved. Johnuniq (talk) 05:42, 26 November 2023 (UTC)
The "trend" was started by Flabshoe1 to Blackpink's related articles. In which Nkon21 followed suit with bulk editing. I personally agreed with Ss112 POV. In addition, I don't see why we're going against MOS guidelines and RfC, did IAR suddenly applies? —Paper9oll(🔔 • 📝) 06:54, 26 November 2023 (UTC)
But there is no MoS provision being violated, and this is not contrary to the RfC results in any way. — SMcCandlish☏¢ 😼 09:27, 26 November 2023 (UTC)
While the MOS doesn't explicitly stated no usage of sronly, the examples provided and wording implied the caption should always exists for accessibility sake. Of course, we haven't even go into table created via templates yet, does the caption that duplicates the heading needs to be hidden also? Then, that would require modification to the templates itself. I don't see why we should be introducing inconsistency as stated repeatedly by Ss112 above or below. If it ain't broke, don't fix it. —Paper9oll(🔔 • 📝) 09:38, 26 November 2023 (UTC)
But redundant visible table headers and captions are "broke". Next, the captions do still exist for accessibility's sake. Are you sure you even understand the nature of this discussion and what {{sronly}} does? I'm getting the impression you think that the captions are being hidden from everyone including the screen-reader users they are there for, but that is not what is happening. Finally, the fact that some templates would have to be adjusted to account for something (if we actually wanted to make an MoS rule for {{sronly}} hiding of redundant captions, which I opposed in the first place, while also opposing one editor here's apparent belief that this use of {{sronly}} should for some reason be prohibited) is never a reason to not do something, or half of MoS would just be deleted. In actual reality, of course, the template tail does not wag the encyclopedic dog. Templates are tools of convenience for us, and must be bent to our needs; they are not the (or even "a") purpose of the project. — SMcCandlish☏¢ 😼 00:03, 27 November 2023 (UTC)
Broke where? MOS doesn't states nor implied that unless I'm blind myself. Neither, did I stated it was removed completely because of {{sronly}} usage. The only thing broken I see is introducing inconsistency, and yes, the template should and must also be updated to match if there is where the consensus is heading to ensure consistency in album/song articles. Regardless, my stand remains the same, and this would be my last reply here to you. —Paper9oll(🔔 • 📝) 00:35, 27 November 2023 (UTC)
Broken everywhere we have redundant table captions, for everyone not using a screen reader, by the very fact of being redundant. We do not need a "rule" to write non-redundantly; we just write non-redundant because it is better writing. WP:COMMONSENSE exists for a reason. There is no principle anywhere on Wikipedia that article content has to be consistent from page to page (and lots of guideline material to the contrary, e.g. permitting different date formats, different English-language dialects, different citation styles, presence or absence of infoboxes, different content sections even in the same article type like scientist biographies or whatever to best suit the exact article subject, and so on). It would not be bad thing for articles to consistently use {{sronly}} to hide, for non-screen-readers, table captions that are redundant, but there is no evidence that the community wants a rule to require such a consistency. Meanwhile it would be a bad thing to undo hiding of completely redundant table captions, for non-screen-readers, on the basis of a completely imaginary idea that articles must be completely consistent from one to another. My mind is kind of blown that I've had to spell this out more than once for more than one user here. — SMcCandlish☏¢ 😼 01:00, 27 November 2023 (UTC)
I have to lean toward the interpretation of Johnuniq and Nkon21, for captions of this sort. They are entirely duplicative of the table headers, and serve no function for fully-sighted users, but are arguably necessary as navigation points for users of screen readers, so keeping them but putting them in {{sronly}} is a good idea. I can imagine some cases where table captions are more informative, for both sets of readers, and in such cases should not be hidden. The fact that Nkon21 thought to use {{sronly}} on the redundant ones before anyone else did doesn't make it somehow an error or a problem. "Nobody has raised a large concern" = no one really cares all that much either way. No harm is being done by these specific caption-hidings, and the result is demonstrably better (in being much less redundant) for fully-sighted readers at no cost to sight-impaired readers, so overal what Nkon21 has been doing (at least in these specific cases) is a net benefit and not just "cosmetic". — SMcCandlish☏¢ 😼 06:48, 26 November 2023 (UTC); revised 00:03, 27 November 2023 (UTC)
Long digressive argument
@SMcCandlish: If that is to become the consensus that forms, it should be noted somewhere, perhaps on MOS:DTT, that if the table caption duplicates the section headings they can be hidden, because it's not stated anywhere and for posterity (and to cite) it should be. But I can still see what is considered "informative" and requires a caption being visible to both sets of readers being a significant point of contention. I must say, not that articles will be ever uniform in most regards, but it's of no benefit to anybody for it to be inconsistently applied—some tables on the articles having sr-only, some tables not having captions at all, and editors (like Nkon21) only caring to hide and even actively reverting over having captions in their topic area of music hidden, whereas every other (or most other) music articles have captions visible to fully-sighted readers in tables. At least in that regard I'd like to have uniformity as to whether they "should" all be hidden from fully-sighted readers or not, because for the last three years I've been trying to make them consistent. Ss112 07:18, 26 November 2023 (UTC)
WP:NOT#BUREAUCRACY and MOS:BLOAT and WP:CREEP. Not everything that editors do that isn't against consensus has to be written down as a rule (or a codified exception to one) to follow. MoS and other guidelines would be much, much longer otherwise, and all we would do is litigate constantly about what to add to them and what they should say. Every line-item added to a guideline or policy is a potential morass of conflict with some other rule somewhere; WP:Policy writing is hard. Basically, "that which is not forbidden is permissible" (cf. WP:EDITING policy), and we have no reason to write down everything imaginable that is permissible. Something should be added to a guideline only with consensus, and only when it needs to be added to forestall longterm, repetitive fights between editors. So, far only one editor that we know of has ever raised a concern about this (and primarily on rule-based and hypothetical-leaning grounds rather than on arguments about actual utility to readers); that's really not justification for a new rule-making. The outcome of this discussion alone (whatever that outcome will be) should be sufficient as something to refer to. As for "it's of no benefit to anybody for it to be inconsistently applied—some tables on the articles having sr-only", that's demonstrably not correct, because reducing pointless redundancy even in a single article is a net benefit at that article. The very fact that "articles will be ever uniform in most regards" (which is correct) means we have no reason to be concerned about lack of someone going around to "consistentize" thousands or tens of thousands (who knows?) of articles in short order and applying the same markup change. Doing it robotically could even raise WP:MEATBOT concerns, as well as hide captions that are actually informative for both sets of readers, which you seem to have a concern about in the first place. — SMcCandlish☏¢ 😼 07:58, 26 November 2023 (UTC)
@SMcCandlish: I was trying to echo what @Johnuniq: said above, about what exactly Data tables should always include a caption means. I meant it could be specified in a few words. I never get involved in trying to change guidelines or policies, so my thinking this one exception is worth additional specification on a how-to guide (not the guideline itself) is hardly worth bringing up an argument that if this were always the case the Manual of Style would be much longer about. It's a suggestion. As for the WP:MEATBOT comment, no disrespect but I lost the train of thought you were on—I interpreted that as you saying that my "consistentiz[ing]" the music articles that have tables on them by making them have visible captions is me acting like a "meatbot", and as that applies to editors making a lot of errors in fast editing I hardly see how that would make sense in relation to me if that's the case. As for your "rather than on arguments about actual utility to readers", I know you didn't explicitly say so but I don't think it's at all a negative for me to try to seek additional input on somebody trying to enact what I think is still a cosmetic workaround because they've decided captions are now redundant and they don't want to see them (and I say cosmetic because the caption is still in the HTML, just not visible in the output). I thought maybe somebody might argue that captions are of use to fully sighted readers in a way I had not considered or some such. Ss112 08:53, 26 November 2023 (UTC)
Whether a caption "should always be included", for the benefit of screen readers, is irrelevant to whether it is permissible to hide redundant ones from non-screen-reader users. And "in a few words" isn't relevant either; due to their nature, table captions should almost always be just a few words. On MEATBOT: To clarify, I was responding further to your argument that there was "no benefit" to hiding redundant captions inconsistently across articles, which necessarily implies that if there is no consensus against what Nkon21 is doing, that it should be done everywhere, necessitating that someone(s) actually do it. That doesn't mean it is necessarily you doing it. Someone doing this robotically across thousands of articles, without making more substantive edits at the same time, and perhaps doing it inappropriately in some cases (of non-redundant captions) would probably trigger MEATBOT objections. I.e., it is something to do with thought and care, on an as-needed basis, and hopefully in a way that doesn't trigger people's watchlists over and over again for a comparatively trivial kind of change that no one is clamoring for. This is about on the same level as tweaking a citation's parameters in ways that just make it more consistent with the rest of the citations in the page (per WP:CITEVAR) but without actually improving the citation in any way for readers. Editors don't like such trivial tweaks being done (thus MEATBOT policy) unless they are part of a more substantive edit. Your understanding of what "cosmetic" means in this context does not agree with Wikipedia's definition (for which, see WP:COSMETICBOT): the very fact that it makes a meaningful difference in the rendered output makes it non-cosmetic, axiomatically. "I thought maybe somebody might argue that captions are of use to fully sighted readers in a way I had not considered or some such." But they're not, so what is the purpose of all this circular argumentation against Nkon21's (and Flabshoe1's) demonstrably useful table tweaking and your near insistence that we need to address it one way or another in a guideline? We just don't. It's not harmful and it is helpful (at least in the cases diffed so far), but really no one cares much either way, so there is no rationale to make a rule to enforce it site-wide, much less a rule against doing it. This has all the earmarks of a tempest in a teacup. — SMcCandlish☏¢ 😼 09:27, 26 November 2023 (UTC)
Good stuff, but you're replying on automatic. Please just consider how odd it is that the guideline says "Data tables should always include a caption" but someone goes around making captions invisible which effectively removes them. Something is needed to clarify the situation even if it's a discussion somewhere focused on that one issue so it can be linked to. Johnuniq (talk) 09:46, 26 November 2023 (UTC)
"making captions invisible which effectively removes them" isn't accurate. They exist almost entirely for scree-reader users (some uses of them that would be of benefit to fully-sighted readers may exist here and there, but they are rare), and the changes in question have no effect on those users, nor has anyone proposed (or, that we know of, engaged in) hiding the ones that are not just redundant reiteration of the table headers. And this already is "a discussion somewhere focused on that one issue so it can be linked to" (ultimately in a talk archive page), though this could also be re-done as a more clearly stated RfC, I suppose. If both you and Ss112 are convinced that the MoS section about this should explicitly mention using {{sronly}} around table captions that are redundant, then I'll stop objecting to the idea, despite being a strong resister of more MOS:BLOAT. But so far, Ss112 appears actually opposed to use of that template for this purpose at all, and rather singlemindedly bent on pillorying Nkon21 (maybe also Flabshoe1 now) for making this novel use of it, as if WP:EDITING policy didn't exist. MoS talk pages are not a disciplinary venue, there is no actual disciplinary issue here in the first place, and MoS pages (and other guidelines) do not exist to enshrine random editors' passing and overreactive ideas about what should or should not be permissible – only to record consensus-accepted best practices and to have, when necessary, often arbitrary rules that simply forestall recurrent editwarring. The only "drama" about this at all has been manufactured out of thin air by Ss112. — SMcCandlish☏¢ 😼 00:03, 27 November 2023 (UTC)
@SMcCandlish: Okay, this is going nowhere and now resulting in misunderstandings. My "in a few words" comment was meant to mean if we were to specify somewhere "what exactly Data tables should always include a caption means" (as Johnuniq has just said), not the wording of table captions. In addition to that, I disagree with your "tempest in a teacup" comment, general argument, and unnecessary refactoring of this very section's heading and inserting your own POV ("redundant") while implying I'm the one who was not being neutral by apparently being "alarmist" and "misleading" with my original heading, when this is not a formal RfC nor did I intend it to be a pseudo-one so there was no imperative for me to be exactly neutral, and I very much consider changing 40+ music articles mass-scale in that area so what exactly was "misleading" let alone "alarmist" I'm not sure. I'm not replying to you any longer here as it's resulting in unfavourable characterisations of why I came here, what I've written and I'd prefer you not do that and that not happen at all. I would like a variety of editors commenting and my replies seem to be just prompting more long passages from you that I feel are going to discourage anybody else from offering their input. Thanks. Ss112 10:00, 26 November 2023 (UTC)
I've addressed most of this in user-talk because it's not actually pertinent to this discussion, which should remain focused on the actual subject of using {{sronly}} on redundant table captions. The short version: The fact that the ones at issue above are redundant is not a "POV", but a bare fact; and your original heading was alarmist and misleading in four different ways, as detailed at your user page. That said, this round-in-circles argumentation is in fact making for a long blob of text here that may be discouraging to other participants, so I'll be happy to collapse box all this digression. — SMcCandlish☏¢ 😼 00:03, 27 November 2023 (UTC)
I agree that having much less redundancy is a net-benefit for articles as visible dual captions offer zero net-benefit for either sighted or screen readers in any substantial way. If they offer no use, then I don't see a strong argument here against the use of Sr-only that's not WP:OTHERCONTENT. ɴᴋᴏɴ21❯❯❯talk 20:31, 26 November 2023 (UTC)
Resolved dispute about thread heading
A point of order: I changed the original confusing heading to "Making redundant table captions screen-reader-only", and this has since been altered again to "Making table captions screen-reader-only" which is grossly misleading. There is no evidence of any kind that anyone has been, or has even proposed, using {{sronly}} to hide all table captions from non-screen-readers, only those that redundantly reiterate the content of the table headers. That is the only thing that has been under discussion here, and the only thing demonstrated in any diffs. The fact that someone is editwarring to keep the title of this discussion alarmist and misleading is a bad sign, and will likely trainwreck the discussion. Someone should probably open a more formal RfC on this matter (which I think is what Johnuniq wants to see happen also), perhaps at WP:VPPRO since ultimately this could affect a large number of articles in any category, not just the music one that this discussion opened with. — SMcCandlish☏¢ 😼 00:53, 27 November 2023 (UTC)
@SMcCandlish: It is not "grossly misleading" at all. Nkon21 hid all the table captions on articles that I could see. "Redundant" is a loaded word and I firmly believe it is still your POV, so I removed it from the heading. It is in no way an "edit war" to remove "redundant" from a section heading that you refactored in the first place—I didn't revert you or anybody here, I refactored your refactor, that's it. First you accuse me of being alarmist and misleading, now I'm alarmist, misleading and edit warring when I didn't perform a single revert anywhere here? I invite your input directly and now all you're doing is throwing out bad-faith accusations at me and claim what I'm doing will trainwreck the discussion? I think you and your paragraphs have already derailed this discussion and discouraged other people from replying and it's already a trainwreck. This is ridiculous. Please stop accusing me of things I did not do. Now, I am fine with the heading as it stands. It doesn't need every specification in it. Editors can read from my first comment what I am specifically talking about. This could apply to any number of areas in making table captions sr-only. Just because it started in music where it repeats what is in section headers does not mean it couldn't affect other topic areas and where they have table captions more broadly. Ss112 01:49, 27 November 2023 (UTC)
Already covered in detail at your talk page [3] and mine. "Redundant" certainly is not a "loaded word", it's a descriptive one with an objective definition. Check any dictionary you like. Typical definitions are "characterized by unnecessary words or repetition", "superfluous", "exceeding what is needed or useful", all of which unmistakably, as a matter of plain fact not opinion, apply to literally repeating in a table caption the same words that are in the table headers, which was the only sort of case under discussion, despite your tendentious attempts to raise false editorial alarm by implying the discussion was about hiding every single table header. When someone clearly demonstrates, in discussions on three different pages, why something is misleading and objects to it, reinstating the misleading language and just asserting "it is not" misleading, certainly is editwarring. — SMcCandlish☏¢ 😼 03:54, 27 November 2023 (UTC)
I am done replying to you beyond this point because you have taken this in some kind of serious misconduct direction. Please stop posting on my talk page as I have requested here and here; nothing here is as serious as you're trying to make it out to be. I did not edit war and I do not think I am being misleading by removing your claim of table captions below headers being "redundant". That's not an edit war because no reverts took place—I didn't "reinstate" anything. I made one adjustment to a heading. For the record re: your comments on my talk page, Johnuniq "suggesting [...] that "should always include a caption" could ambiguously be interpreted to mean that the caption must always be visible to everyone [...] and that we should have that discussion" is exactly what I meant as well and literally what I tried to get at in this discussion before it got sidetracked. We should be having that discussion. I also never insinuated or stated I wanted the use of sr-only to be forbidden. I don't want it to be as I still see it as useful in other places. Thank you. Ss112 04:35, 27 November 2023 (UTC)
This seems to have resolved itself in user-talk, fortunately. :-) — SMcCandlish☏¢ 😼 08:13, 27 November 2023 (UTC)
It's nearing 2 weeks with no new comments here and I'm wondering how we are going to move forward. Is there a consensus? Or should an RfC be opened? ɴᴋᴏɴ21❯❯❯talk 22:59, 8 December 2023 (UTC)
I don't believe there's a consensus here. I support a (neutrally worded) RfC being started, but also, I don't think there's any rush for there to be a consensus if one is to form here. As SMcCandlish has pointed out, it's not a very watched talk page. Ss112 03:22, 9 December 2023 (UTC)
Well, a) there is no rule against using {{sronly}} to hide redundant table captions; b) doing it is objectively an improvement for fully-sighted readers and does no harm for screen-reader users; c) one editor came here with a wild hare to ban this practice; d) nothing like a consensus emerged to do so; e) the status quo thus has not changed: it is entirely permissible to do it; f) various noise was made along "what if people do it to non-redundant captions?" lines, but there is no evidence of this happening (if it does happen, reverting would be covered by WP:COMMONSENSE and the template's own documentation: it is not for hiding content that is not pertinent only to users of screen readers).The only thing we might want to have an RfC about is whether MoS should recommend{{sronly}}-hiding of redundant table captions, but WP:CREEP and MOS:BLOAT would suggest we should not go there, since this is not something that editors are frequently in conflict about, so no reason to add a rule about it. And it is not a discussion for this page in particular, but for WT:MOSTABLES, since this has no accessibility implications at all. — SMcCandlish☏¢ 😼 06:24, 9 December 2023 (UTC)
@Johnuniq Do you have any thoughts? ɴᴋᴏɴ21❯❯❯talk 09:29, 10 December 2023 (UTC)
In my reply to the OP I tried to clarify the issue to make it easier for others joining the discussion. Apart from that I don't have an opinion except for two points: (1) people should not do mass edits against objection without gaining a clear positive consensus; (2) it's crazy for a guideline to say that a caption should always be included while people go around making them invisible. If there is still a dispute, start an RfC after drafting a comprehensible question. Johnuniq (talk) 09:44, 10 December 2023 (UTC)
it's crazy for a guideline to say that a caption should always be included while people go around making them invisible I'm not sure what's crazy to be honest; the 2020 RfC never suggested that table captions are required to be visible, just that captions should exist. Sr-only does not remove captions and hiding redundant ones do not go against any already established consensus. People who has opposed them so far have solely cited inconsistency concerns, which in my opinion is trivial as the benefits outweigh it. ɴᴋᴏɴ21❯❯❯talk 09:53, 10 December 2023 (UTC)
What if I went around making things I didn't like invisible? And people asked me to stop. So I replied "the text is still there; who says it should be visible?". You don't think that would be somewhat crazy? Johnuniq (talk) 02:08, 12 December 2023 (UTC)
Not a valid comparison, on at least two grounds: Hiding redundant captions from the fully-sighted audience is a practicality matter not an WP:IDONTLIKEIT one; and making content invisible to/hidden from everyone is different from making screen-reader content available to screen readers but not pushed on everyone. In order for your premise to be valid, the {{sronly}} template would never have existed (or at very least would be WP:TFDed right this second and would be deleted with prejudice, but of course that's not going to happen). To put it another way, by your reasoning (at least taken to its logical conclusion), we would also have to find a way to force the display of all alt text for images so that non-screen readers could see it. — SMcCandlish☏¢ 😼 21:28, 12 December 2023 (UTC)
@SMcCandlish: I am not intending to start another argument, but please do not put words into my mouth. Nowhere in my original reply or in this thread have I said we should "ban" the use of sr-only templates. I believe I even said somewhere on your talk page I didn't support "banning" the practice—I'm quite sure I said somewhere it has a use. Regardless of our long disagreements over other matters on your talk page, including this very section's heading, my intention here was to start a discussion on whether what Nkon21 was doing should be done or not, not to outright "ban" the use of the sr-only template. Unfortunately this hasn't gotten the amount of feedback I would have liked and has gotten so sidetracked I no longer particularly want to engage here so am trying to keep my replies as brief as possible. If I wanted sr-only to no longer exist, I would have proposed the deletion of the template, not come here or sought others' input. I fully agree with what Johnuniq said dated 09:44, 10 December 2023. Johnuniq has gotten to the point and made my intention clearer here than I have. Thus I no longer want to be involved in this, but I would really prefer editors not misrepresent or misstate my purpose because of what they believe when I never explicitly said such things. Thanks. Ss112 13:42, 11 December 2023 (UTC)
I'll strike mine too, then. No one needs to wade through this. The entire thrust of your participation in this discussion has been prohibiting Nkon21 or anyone else from doing this, which is clearly arguing for a ban on it even if you didn't use the word "ban". (That said, you have also veered at times into statements that seem to indicate you're actually taking a devil's-advocate position and making these arguments simply because you think there is some kind of guideline inclarity or conflict you can force to be resolved this way, which is a simultaneous WP:POINT, WP:LAWYER and WP:BUREAUCRACY behavior problem). This entire thread never should have existed, because Nkon21 and Flabshoe1 were not breaking any rules or doing anything unhelpful, and there is no evidence of any kind of conflict or other problem caused by their edits, so you have generated a mountain out of molehill for no reason at all. It might have been reasonable to ask a neutral and claim question about whether these edits had any accessibility or other implications, but instead you came in here with accusations and ranting against another editor, claiming what amounts to wrongdoing by them, with no evidence of any kind. You have consistently failed to understand what "cosmetic change" means, and repeatedly completely confused the notion that the table caption should exist for the benefit of screen-reader users, with the unrelated notion that this caption must be visibly presented to everyone even when it is redundant with the table headers. This (and the associated user-talk circular argumentation) has been a total waste of time and a strain on editorial good will. Not to mention all the editwarring to suppress particular wording you didn't understand, and other shenanigans. — SMcCandlish☏¢ 😼 14:09, 11 December 2023 (UTC); struck 15:30, 11 December 2023 (UTC)
"If there is still a dispute, start an RfC after drafting a comprehensible question" is correct. There seem to be two editors who have some concern about this, and I don't think that's sufficient grounds for an RfC; RfCs consume community time, attention, and energy, and there would have to be a strong showing that hiding redundant captions violated some kind of principle or goal, but there is zero evidence of that anywhere, so we already know how such an RfC would turn out. But go ahead and do one anyway, if you insist. — SMcCandlish☏¢ 😼 14:09, 11 December 2023 (UTC)
Side question re aria-description
In our modern times, is using the aria-description attribute of a <table> tag instead of a caption a suitable way to introduce the table to screenreader users without producing disruptive redundancies for visual users? Do modern screenreaders pick up that attribute when a user calls for a listing of the tables present on a page? If so, is that technique worthy of consideration? Largoplazo (talk) 01:12, 27 November 2023 (UTC)
It would be pretty hot if this were usable navigationally, and obviated the need for the captions. I'm skeptical, since it seems like the HTML specs wouldn't have both at this point if they were redundant/conflicting. — SMcCandlish☏¢ 😼 08:13, 27 November 2023 (UTC)
Links within section headings
At WT:MOS there is a discussion regarding the technical reasons not to put links into section headings. If users here have insight on accessibility or technical reasons for the practice, please join us: Wikipedia talk:Manual of Style#Header links: technical reasons. — HTGS (talk) 04:13, 13 December 2023 (UTC)
single-item lists
The template {{infobox cocktail}} automatically forces a bulleted list for its main-alcohol parameters; bulleted lists in infoboxes aren't unheard-of, though rare. However, that template forces a bullet even for single entrants, making the oxymoronic single-item list. Given there is no actual list created, should that template be invoking list markup for single variables? For example, in the infobox's implementation at mojito, there's a bulleted list with one item (rum). Given how the bulleted-list markup interacts with other variables like scrapers, screen readers, and more, are there any technical or accessibility (or grammatical or stylistic) problems caused by a 'list' that then only has one entrant? — Fourthords | =Λ= | 15:27, 30 December 2023 (UTC)
As a screen reader user, not really ... it's slightly annoying but not unusual at all and certainly not the end of the world. Graham87 (talk) 02:25, 31 December 2023 (UTC)
Advice on impact of image links on screen readers
Hi. Over at Wikimedia Commons, there is currently a discussion about whether removing the links from images to the image details page will help users of screen readers. It would be useful if any users of screen reader software can provide their thoughts on the discussion. See c:Commons:Village pump/Archive/2024/01#Usage of files with link to file removed. From Hill To Shore (talk) 17:29, 3 January 2024 (UTC)
WP:NCTV discussion on titles of TV season episode list articles (punctuated or not)
Please see: Wikipedia talk:Naming conventions (television)#Follow-up RfC on TV season article titles. This is round two of a consensus determination on how to format the names of such articles, and an accessibility concern about one of the options has belatedly come up (namely, using no punctuation of any kind between series title and season designator, just relying solely on italics to clarify). — SMcCandlish☏¢ 😼 05:34, 8 January 2024 (UTC)
The explanation came from University of Minnesota:
“Screen readers will read the content of a table in a linear fashion — left to right, top to bottom.”
“Complex tables that include nested tables or that require two rows in order to explain the information contained in the columns, are more difficult to tag for accessibility.”
Simple data tables can be easily navigated. They may not cause too much cognitive load. However, complex tables especially with nested elements, are more difficult to tag for accessibility, so should be avoided for data presentation unless the reading order is made logical for screen readers to follow. Moxy- 15:43, 13 January 2024 (UTC)
Do you have a link to that page with the quote? So I can read more.
And specifically what do you think of the nested tables used to surround the examples at Help:Collapsing?
As opposed to the many example tables in the various sections of Help:Table (wikitext and result)? Help:Table does not use nested tables for those examples. It uses divs. I believe Graham87 approved of divs for allowing 2 tables to wrap. For example; from a previous discussion:
Total number of matches played in official competitions only.
Narrow your browser screen to see the tables wrap (one drop below the other). Works in mobile view too.
--Timeshifter (talk) 17:14, 13 January 2024 (UTC)
I don't want to deal with this. Graham87 (talk) 08:08, 14 January 2024 (UTC)
Query about anchor behavior
@Graham87: Something I've been wondering for some time is whether it makes a difference in screen readers whether an HTML anchor is at the beginning of a line or the end of one as long as its on the same line. I mean anchors such as created by <span class="anchor" id="Foo"></span>, or by use of the {{anchor}} or {{vanchor}} templates. Visually what happens is the browser jumps to the line and (at least in some browsers) the line gets highlighted. This kinda-sorta suggests that the screen reader would read from that line onward, but for all I know it might read from the span point onward, or it might vary radically from screen reader to screen reader. I ask this mostly with regard to headings in which a former name of the section is preserved as an anchor for incoming-link purposes. These spans mostly seem to be added to the end of the heading (because putting them at the front of the heading makes it hard to tell what the section is when in wikicode viewing mode). — SMcCandlish☏¢ 😼 08:47, 14 January 2024 (UTC)
I don't think so, but screen readers behave oddly with anchors at the best of times, so it'd be hard to test properly. I wouldn't change that practice just for that reason, anyway. Graham87 (talk) 09:03, 14 January 2024 (UTC)
Okey-dokey. Thanks for the feedback. — SMcCandlish☏¢ 😼 11:59, 14 January 2024 (UTC)
The only problem with the templates now is that when they're run together with just spaces in between them like at this documentation subpage, both the popular Windows screen readers JAWS and NVDA read them out without the spaces, probably due to the CSS magic (e.g. "1/21/3" instead of "1/2 1/3". I'm going to put commas in between to stop that. Graham87 (talk) 08:42, 14 January 2024 (UTC)
Visually, the result is pretty crapful. One wonders whether some of the alternative whitespace characters might be usable instead. Some potential candidates might be: A) medium mathematical space,   (with a capital first M and capital S) or   and B) punctuation space   or   and C) four-per-em space,   or   and D) three-per-em space,   or  . Those would have the closest appearance to a regular space (without also being non-breaking). — SMcCandlish☏¢ 😼 09:03, 14 January 2024 (UTC)
@SMcCandlish: OK, I've self-reverted. JAWS likes all but the first option but NVDA doesn't 100% like any of them (it reads them as unknown characters)). I'll just put up with it for now. Graham87 (talk) 09:22, 14 January 2024 (UTC)
Well, it's not that bad; if the commas are needed, they are. Maybe there are invisble commas. :-) — SMcCandlish☏¢ 😼 11:57, 14 January 2024 (UTC)
I've come up with another idea ... I used {{sronly}} to make them only visible to screen readers (hopefully without messing anything else up in the process!). We can find all the unusual characters we like, but as the guideline says: "Screen readers have widely varying support for characters outside Latin-1 and Windows-1252 and it is not safe to assume how any given character in these ranges will be pronounced." Graham87 (talk) 14:36, 14 January 2024 (UTC)
From Accessible Rich Internet Applications (WAI-ARIA) 1.1: Content with the role math is intended to be marked up in an accessible format such as MathML ..., or with another type of textual representation such as TeX or LaTeX, which can be converted to an accessible format by native browser implementations or a polyfill library. Our {{frac}} template doesn't do that. --Redrose64 🌹 (talk) 12:01, 14 January 2024 (UTC)
I actually think that {{frac}}(tion) does do just that (within the limits of MW-HTML), but if role screws up the very software it was added for, it’s of course fine for me to remove that attribute. — ChristophPäper 13:50, 15 January 2024 (UTC)
It is clear that essentially anything that represents math can carry the Math role. Yet another example of browsers having incomplete interpretations and the standards not being clear enough to avoid these problems (A common issue with ARIA honestly). I'm personally not very favourable of working around issues like this as it doesn't motivate the companies in question to actually FIX these problems. But as the track record of said companies on fixing accessibility problems is not especially stellar, it is a bit of a balance. —TheDJ (talk • contribs) 14:18, 15 January 2024 (UTC)
Are these nested tables accessible?
My last thread was way too complex of a question. With no simple answers. The following is a lot simpler. The nested tables example below is in use on a help page. It does not wrap (a problem in cell phones, especially in portrait view). Is it accessible? It is followed by the divs method which wraps (narrow your browser screen), and is already acknowledged as accessible.
Pinging Steelpillow since he seems to know something about this from another discussion. Apparently, some nested tables, when formatted correctly, are accessible. See:
{|class="wikitable sortable mw-collapsible"|+ {{nowrap|A longer table caption needs to wrap}} for cell phones, etc.! Name !! Score|-| John || 59
|-| Bob || 72
|}
A longer table caption needs to wrap for cell phones, etc.
Name
Score
John
59
Bob
72
With divs:
Code entered
{|class="wikitable sortable mw-collapsible"|+ {{nowrap|A longer table caption needs to wrap}} for cell phones, etc.! Name !! Score|-| John || 59
|-| Bob || 72
|}
Output produced
A longer table caption needs to wrap for cell phones, etc.
Both examples are fine by me. Graham87 (talk) 15:11, 14 January 2024 (UTC)
Works just fine on my screen reader. Moxy- 15:15, 14 January 2024 (UTC)
steelpillow here. Both the table and css versions appear sensible to me, though I do not have a reader handy. Unfortunately, "accessible" and "conformant to WCAG" are not necessarily the same thing. In practice, "accessible" means that a sensible range of screen readers work on your page. But some screen readers are more sensible than others, as are ways of using tables and/or divs. For example the html attribute:"value" role="presentation" can desensitise the screen reader to some issues - but it can create other issues of its own. Different readers may respond to it differently. What really kills accessibility is when the code breaks normal flow. Be it nested tables or cunningly repositioned divs, if the ordered flow of content in the page code does not match the intended ordering presented to the user, then all hell will break loose. This can happen with, say, a div floated to the right so it will be read afterwards, but coded into the page first so that the lefthand content, placed after it in the code, flows down alongside it and visually presents first. Similarly, you can nest tables badly so that the visual flow keeps jumping between tables instead of just dealing with the second table as a unit. IMHO the official guidelines are just too deep down the techno rabbit-hole. The mantra should be: NEVER BREAK NORMAL FLOW. And neither of these examples does. At least, that is my experience, but I know little of the current official state of play. — Cheers, Steelpillow (Talk) 17:11, 14 January 2024 (UTC)
Thanks steelpillow. I think I am beginning to vaguely understand. :)
This actually makes some sense to me: "This can happen with, say, a div floated to the right so it will be read afterwards, but coded into the page first so that the lefthand content, placed after it in the code, flows down alongside it and visually presents first."
Pinging Jroberson108 since he is working on this stuff here:
I would stay away from using tables for layout purposes or oddly floated divs. These divs, however, don't use the float style and will always follow the one above it either to the right on wide screens or under it on narrower screens. The main purpose of the divs being used this way is to be responsive based on the screen size, something a table can't do.
I'm looking at these using Chrome on my Android phone in portrait orientation. For the divs, each box is 100% the width of my phone. On a wider screen, the divs appear next to each other reducing some of the white-space. For the table layout, the entire table is more than 100% the width and requires horizontal scrolling to see the whole table. On a wider screen, the table layout doesn't change. On a narrower screen the divs have less text wrapping than the table.
As I understand screen readers, they narrate left to right, top to bottom. For the divs, the entire code portion is read first followed by the entire output portion. For the table layout, because there are headers, there may be a bit more to read: headers first, then the code header and code portion, then the output header and the output portion. If the headers were emptied and moved into the code and output rows (no headers), then it would probably be less to narrate, but again not responsive and more text wrapping on narrower screens. Jroberson108 (talk) 18:57, 14 January 2024 (UTC)
I adjust the leftmost div with style=max-width:Xem; in these types of pairs. So that the leftmost div is not too wide on desktops. This way both the left and right divs can be responsive and fit on one line on a desktop, and even sometimes in landscape view on cell phones. That is if the rendered table in the rightmost div is not too wide.
I am about halfway through Help:Table in adjusting the leftmost divs to make the pairs more responsive. --Timeshifter (talk) 20:14, 14 January 2024 (UTC)
@Timeshifter: I usually omit the extra green border and padding on the div, which on mobile gives more width for content by reducing the left/right white-space and also reduces text wrapping. Jroberson108 (talk) 01:08, 15 January 2024 (UTC)
I just removed almost all the padding in the div pairs on Help:Table and in the above divs. That helped a little. Nearly all the white space has now been removed around the divs.
I tested removing the green border. That did almost nothing concerning removing white space since they are only 2 pixels wide.
The green borders help with clearly seeing the pairs. A single pixel is not nearly as good. The green really comes out with 2 pixels. A 1 pixel green border looks almost gray, and can be confusing when next to some of the gray table borders. So it helps with accessibility for people like me that don't like turning up their monitor too bright. That makes everything a little grayer. --Timeshifter (talk) 03:14, 15 January 2024 (UTC)
@Timeshifter: Remember, when the border is set to 2px, that's 4px total (left and right) extra width as well as a doubling of the extra padding on each div. To clarify, removing the border doesn't affect white-space, it would provide more space for content (less wrapping), and removing padding does both. You probably shouldn't rely on color to distinguish something from another and assume total color blindness would see it as a shade of gray similar to the borders that come with syntaxhighlight and tables (more at Color blindness), as you said you experience when you decrease your monitor's brightness. If there is an issue with confusing one border with another, you can play around with changing the border style from solid to dashed (see border), then color shouldn't matter. But, this does nothing for screen readers that would, in this case, rely on the headers above the code and table output, so proceed with that in mind. Jroberson108 (talk) 08:56, 15 January 2024 (UTC)
I did some screenshot viewing via this color blindness tool I like:
I tried out red and lime borders on parts of Help:Table, took screenshots, and looked at them in the tool.
Red is better than lime. Red ends up darker than lime after going through the various color blindness variations there. So I changed the Help:Table borders for the wikitext/result pairs to red.
I also tried dotted and dashed borders. A solid 2 pixel border is better, more distinguishable, more accessible.
Red is better looking than the neon green. For the types of color blindness, black on a white(ish) background should offer the most contrast, enough contrast from the muted syntaxhighlight/table borders, and distract less from the reading experience for those without color blindness (red yells look at me). The greater black contrast should also allow for a narrower 1px border.
Still not sure why a bordered box needs to be around a header and its code/table block that immediately follows, which seems like an overemphasis of what the headers are already doing. It's already accessible and saying it's "more accessible" is arguable since bold red generally screams look at me and distracts from my reading experience causing me to focus on the border instead of what's in or outside the box border. For me black would scream less. In my opinion, the only instances where a border might be needed is if some borderless output might be confused with the prose around it. Example, centering tables that has prose in the output that might be confused with other prose, which arguably the outputted prose could be removed. Another example might be when a borderless table is outputed above short prose that might look like it is apart of the table.
BTW, setting max-width everywhere can cause unnecessary text wrapping (harder to read) on wide monitors like in the wikitext of Help:Table#Vertical alignment in cells. It's best to let things span the full width of the page if they need to. If the two blocks are narrow enough, then they will naturally wrap to one line on wider screens to help reduce white-space. Jroberson108 (talk) 10:42, 16 January 2024 (UTC)
I got rid of the color borders on the Help:Table divs. The 2-pixel black border is enough. I tried a one-pixel border, and it is not enough in my opinion. I adjusted or removed all the width settings. To get the best results in both mobile and desktop. --Timeshifter (talk) 22:22, 16 January 2024 (UTC)
Looks better than the red and the neon green. This is probably getting a bit off topic from accessibility, so I'll keep it short since it relates to the divs above. The first table in Help:Table#Width, and probably others, is wider than my Android portrait screen and pushes the page wider so the whole page has to be scrolled horizontally. Normally without the divs you can horizontally scroll that one table without the push. Changing the display style from inline-table to inline-grid brought back the table scroll without the push. Maybe you can test on your desktop and iPhone too, and if it works well then change them all on the page? Jroberson108 (talk) 23:50, 16 January 2024 (UTC)
I tried things in this sandbox, and it seemed to make a difference there in portrait view on my iphone:
So I changed them all to inline-grid there at Help:Table. I think it helped, but I am not sure. There is still some wobbliness at times in portrait view. How about you? Is so, what could be causing it?
By the way, I changed to black div outlines to help accessibility for color-blind users. Red or green both end up being gray for some of them. Black is much more distinctive.
The 2-pixel black outline makes more of a difference in portrait view on cell phones. It is easy to get lost in that long column of stuff in portrait view of Help:Table. So when one sees the 2-pixel outline one soon learns that one is viewing a div pair. That is not always clear with a 1-pixel line. It is important for accessibility in the broader sense on cell phones. Though we are probably off topic in the traditional sense of accessibility. We should probably continue elsewhere. There is one accessibility question though:
Graham87, Moxy, etc.. Is the div pair higher up ("With divs") still accessible? They are now using display:inline-grid instead of display:inline-table. --Timeshifter (talk) 18:18, 17 January 2024 (UTC)
You already mentioned the border change in a previous post, which I said it looked better than what it was before. Not sure what "wobbliness" you are referring to? After the display style change, your sandbox and the Help page allow me to scroll wide tables when in that div. The only thing left pushing the page width on portrait is the big table at Help:Table#Table syntax comparison. It works if I remove the sticky, which isn't really needed on a table with two easy-to-remember column headers; also sorting isn't needed. Jroberson108 (talk) 20:06, 17 January 2024 (UTC)
I removed the sticky header there. I closed all the TOC sections of Help:Table and started down the page only opening one section at a time and looking for horizontal "wobbliness". :) Then I closed that section and opened another. This section seems like it can't stay in one horizontal position as I scroll through that section: Help:Table#More cell operations. Do you have the same problem there? If so, what do you think is causing it? I looked at the rest of the TOC sections and I don't see the problem in them. --Timeshifter (talk) 00:57, 18 January 2024 (UTC)
The large table scrolls correctly now. Still not sure what you mean by horizontal "wobbliness", which there is a clock image in that section and I can't help but think of Dr. Who, "Wibbly wobbly, timey wimey". Anyways, do you mean the page width gets pushed wider when you open the section and returns when closed? I opened and closed each section on Android Chrome and Firefox and had no issues. It might be the large table in the last sub-section at Help:Table#Individual cell borders. You might can copy the entire page to a sandbox and turn all the sub-sections into main sections and narrow it down that way. Otherwise, I don't have an iPhone, so you will have to get with someone who does. If further discussion about content is needed, maybe move to that talk page? Jroberson108 (talk) 01:48, 18 January 2024 (UTC)
Jroberson108. Quick note here rather than start a whole new thread elsewhere for one comment. See User:Timeshifter/Sandbox240#Setting cell parameters. I added some spaces in the filenames of the first wikitext div. See the revisions. That solved the problem by allowing text to wrap better inside that wikitext div in portrait view in my iphone SE 2020 with only a 4.7 inch screen. And I use a larger text size probably than many people. So without those spaces that wikitext div extended slightly past the edge of the screen. So the column is no longer fixed firmly in place horizontally when scrolling up or down in portrait view. The columns slips right and left a little. --Timeshifter (talk) 16:16, 19 January 2024 (UTC)
The colon separates namespace from pagename, and we do not place spaces on either side of that colon. You are attempting to change a twenty-year convention. --Redrose64 🌹 (talk) 18:54, 19 January 2024 (UTC)
Wikitext for image to right: [[ File: StarIconBronze.png| thumb | 100px | Spaces ]]
See diff. Do you have any policy on this specifically for Wikipedia? Because I have often seen spaces before file names, and surrounding their posting parameters. For many years. The only place a space doesn't work is at the end of the filename, or before the extension. So what convention are you talking about? It is working on User:Timeshifter/Sandbox240. It works for linking too:
I know it works, but that's simply not the way we do it. People use regular expressions to search for certain patterns. So do scripts, and bots. These regexes are necessarily more complicated if they have to be coded for extra spaces that are completely unnecessary. Please don't make things more difficult. --Redrose64 🌹 (talk) 21:45, 19 January 2024 (UTC)
Redrose64. You are making new policies up again. Like trying to require editors to use <br />. See the <br> section of Help:Line-break handling where now people can use what they want. See this version of the div pair in question:
There are spaces before and after colons, semi-colons, equal signs, etc.. The wikitext produces the exact same result. Lower your font size if necessary to see the 2 divs show on one line.
Show me a regex, script, or bot that is effected by any of the spaces.
And even if you find one, it is still not more important than making Wikipedia pages work well in portrait view in cell phones. Since the majority of pageviews on Wikipedia are from cell phones, I believe.
And we are talking about only a few cases where a space is needed after "File:" on div pairs. Most div pairs only need spaces in the styling to make the wikitext half of the div work in portrait view. So please stop making a federal case out of nothing. --Timeshifter (talk) 22:37, 19 January 2024 (UTC)
Please stop twisting my words. I never said that markup with spaces doesn't work, nor have I claimed policy. Also, we are talking about only a few cases where a space is needed after "File:" on div pairs is blatantly untrue: the space is never needed, and <div>...</div> pairs have absolutely nothing to do with how Wiki markup is processed. --Redrose64 🌹 (talk) 00:02, 20 January 2024 (UTC)
"not the way we do it." It's not the way you do it.
"the space is never needed,". Have you read and understood what I wrote, and why I added the spaces where they were added? I already told you why it was needed. Do you think I am making this up? Tell me what you think I wrote. --Timeshifter (talk) 02:34, 20 January 2024 (UTC)
@Timeshifter: I'm not sure I follow completely, but for displayed markup, I do recommend adding white-space in style values after the colons and semicolons (excluding the end). Those are the standard locations to add spaces in inline CSS styles and is also how browsers reformat them when displayed through page inspect. This helps with readability and text wrapping both when editing source code and viewing displayed code.
I agree with Redrose64 that following a standard would make regular expression searches easier. For example, when I'm trying to modify a large table with what should be a simple regex, I usually have to spend most of my time adjusting the regex and standardizing the code for consistency before applying the final find/replace. It's a big headache.
Also, adding spaces to code that isn't displayed as code won't affect anything displayed on the page since they are ignored during rendering, so most of the spaces you added probably don't do anything. Finally, and I already mentioned this in a previous post, removing any extra left/right padding and margin on the divs would create more width for content displayed on a small portrait mobile screen. Adding a space before bars like [[File:StarIconBronze.png |120px |Bronze star icon]] is a standard I've seen with citations, and seems ok if displayed as a code example so text wraps nicely. Jroberson108 (talk) 00:40, 20 January 2024 (UTC)
I removed the border and padding altogether (see version) from the problematic wikitext div at the top here in this section:
The problem remains on my 4.7 inch screen in portrait view on my iphone SE 2020. There is a "legal" break point space right after the filename extension, and before the bar as you suggested. That's not good enough.
There are 2 pair of divs with this problem for me on Help:Table. Both have images in them. Here is the other div pair:
Part of the problem is that the SyntaxHighlight extension uses a larger font (character length, width, and height) than the surrounding text. See: mw:Extension:SyntaxHighlight#Styling where it talks about this: "If the displayed code is too big, you can adjust it by putting the following into the MediaWiki:Common.css page in your wiki".
And one of the image filenames in question is longer than the other wikitext names in the divs. The break points after the image filenames do no good.
I guess another solution would be to find an image with a shorter filename. I will look.
I found star images with shorter filenames. That fixed the problem. I even returned the 2px border for consistency, though I removed all padding except on the left side so that "Wikitext" wasn't touching that border. --Timeshifter (talk) 03:56, 20 January 2024 (UTC)
Still fine with me as a screen reader user. Graham87 (talk) 03:48, 18 January 2024 (UTC)
Paragraph breaks in a comment
Note: This discussion moved from user talk page to get more input.
Hello Timeshifter,
It seems that we have gotten into a few disagreements lately. I hope you know that I bear no ill will towards you; I firmly believe you are doing what you believe to be in the best interests of Wikipedia. I hope that our editorial disagreements do not stop us from being friendly towards one another.
I wanted to drop you a note about making paragraph breaks in a comment. Per MOS:PARABR, using multiple colons to create paragraph breaks is not accessible. We use list markup for comments, and generally one entry in the list should correspond to one comment. When you use colons like this:
:Here is one paragraph.
:Here is another paragraph.
:Here is a final paragraph. [SIGNATURE GOES HERE]
screen readers cannot distinguish it from:
:Here is one paragraph. [UNSIGNED COMMENT]
:Here is another paragraph. [UNSIGNED COMMENT 2]
:Here is a final paragraph. [SIGNATURE GOES HERE]
:Here is a paragraph. {{pb}} Here is another paragraph. {{pb}} Here is a final paragraph. [SIGNATURE GOES HERE]
{{pb}} works like <br>, but has different semantics. <br> is used to create a visual line break; {{pb}} separates two different paragraphs. Best, HouseBlastertalk 03:41, 13 December 2023 (UTC)
HouseBlaster. I don't think this is true for talk pages.
It has been my understanding that the main thing is to avoid blank lines in indented comments.
It's not such a big deal for talk pages and lists without bullets, know. Screen readers read each list item (or pseudo-item in this case) on its own line, so the separation is still there. The only difference between the two forms of markup above is that in the one with explicit paragraph breaks, each new paragraph is actually read as a blank line. Graham87 (talk) 16:23, 13 December 2023 (UTC)
Graham87. So colons are fine? I have never seen {{pb}} used on a talk page. --Timeshifter (talk) 16:38, 13 December 2023 (UTC)
@Timeshifter: Yep, they're not worth worrying about. Graham87 (talk) 16:46, 13 December 2023 (UTC)
This is a case of technically correct, but practically not. The MoS is mostly focusing on content, where yes, it is 'ideal' to do it like that,. But it's also ideal NOT to use : for indentation, and on talk pages, we do that anyway, because that's how it's been done since 2001 and it's hard to break a habit. It's also very low impact, as Graham also stated in the actual screenreader experience. The one thing that is really annoying is to have double line breaks, because that creates a new list, which is very disruptive in the screenreader annotations. —TheDJ (talk • contribs) 09:49, 14 December 2023 (UTC)
TheDJ and Graham87. Just so I and others are clear, you are talking about a blank line when you talk about double line breaks. For example, if I added a blank line between this comment and the previous comment.
Or if I added a blank line between this sentence and the previous one in this comment.
Are colons still OK to indent it? I am only talking about a table in a comment, not in an article.
I know I can add a left margin to get the same result, but does that even help accessibility?
And it is not easy to figure out the left margin size. For example with the 4 colons used to indent this comment I would have to use style="margin-left:6.4em;" for the left margin of the table. For example:
Caption text
Header text
Header text
Header text
Example
Example
Example
Example
Example
Example
Example
Example
Example
I don't remember editors doing this on talk pages.
@Timeshifter: Yeah colons are fine in situations like this. Graham87 (talk) 01:31, 24 December 2023 (UTC)
@Timeshifter: I can add to that. If a table is indented with colons (as in your first example), the list is continuous; but if an unindented table appears between two indented lines (as in your second example), there are now two distinct lists, and that is essentially a WP:LISTGAP problem. --Redrose64 🌹 (talk) 20:40, 24 December 2023 (UTC)
While the first table is indeed embedded within the list, examining the HTML shows that all of the nested lists are terminated afterwards and then a whole new set of nested lists started with the subsequent comment. I don't know how to avoid this; I tried out some methods but they didn't work. isaacl (talk) 19:57, 5 February 2024 (UTC)
The section to which you linked, Wikipedia:Manual of Style/Accessibility § Multiple paragraphs within list items, does not say using multiple colons to create paragraph breaks is not accessible nor generally one entry in the list should correspond to one comment. It is describing a way to have multiple paragraphs appear within one bulleted list item. Some users will use a bulleted list item followed by an unbulleted list item at the same nesting level. This causes extra list end/start announcements to be made by screen readers, which is inconvenient. isaacl (talk) 23:34, 24 December 2023 (UTC)
Another option I've been using for years is explicit <p>...</p> markup, just without line-breaking in the code. If you do :Yak yak yak.<p>Blah blah blah.</p> that makes a perfectly valid single list item of two paragraphs.
This line demonstrates.
With a paragraph break.
And another one. These will be read out as a single list item with multiple paragraphs.
Explicit <p>...</p> markup around the first part of the list item is not necessary. For large blocks of text you can use HTML comments to create visual line breaks in the code that don't exist in the rendered version and thus do not affect screen readers, like this:
This is paragraph 1 of a list item.
This is paragraph 2 of the list item.
This is paragraph 3 of the list item.
Markup like that is actually easier to read in complex blocks of wikisource material than using the {{pb}} template, though you can use the HTML comment trick with that too:
Start of new list item.2nd segment of list item.3rd segment of list item.
Using the explicit <p>...</p> markup is semantically better than {{pb}}, because the latter does not actually create paragraphs at all; what it does is inject an empty <div>...</div> that really serves no semantic function, specifically the following code: <div class="paragraphbreak" style="margin-top:0.5em"></div> It is nothing but visual spacing by injecting some CSS margin-top. An argument can be made (and probably argued against, from differing viewpoints about Web semantics) that actually just using <br /> (or <br /> <br /> to inject a blank line that the parser does not automatically collapse) is semantically superior to {{pb}}, though inferior (for paragraphization) to <p>...</p>. The {{pb}} template is actually misnamed and misleading. — SMcCandlish☏¢ 😼 00:25, 30 December 2023 (UTC)
@Timeshifter: My username has a capital "B", so I didn't get that ping (lowercase-b Houseblaster is a doppelganger account). Colons create description lists (which we use on talk pages even though it is incorrect). margin-left is the CSS for indenting.HouseBlaster (talk · he/him) 19:19, 5 February 2024 (UTC)
The initial portion of the section on paragraph breaks in a comment is unrelated, as it is about successive list items, which does not fit the scenario in question. The later portion was within the context of embedding a table within a list. There isn't a reason to place the table in question within a list, and so there's no content-related purpose to prefixing it with a colon. Spacing for appearance is best done using CSS. isaacl (talk) 19:50, 5 February 2024 (UTC)
My question is whether using a colon for this is forbidden. And why. It is a lot simpler to use a colon. Versus creating a div with a margin. Or having to do the math to get multiple colon equivalents.
Why should editors have to go to all this trouble for a single wikitext table? Is it really bothering anybody? Even people using screen readers. And see the related section higher up: #single-item lists
See the "Standard usage" section of this version of the page to see the wikitext table indented by a colon. Hopefully someone with a screen reader can look at it too.
Timeshifter, using a colon in that instance is not "forbidden", but it is something that should be fixed. In the single-item lists section above, Graham87 confirms that is an annoyance to have a single-item list when there is not an actual list. — HouseBlaster (talk · he/him) 20:10, 5 February 2024 (UTC)
HouseBlaster. Graham87 wrote: "As a screen reader user, not really ... it's slightly annoying but not unusual at all and certainly not the end of the world". So I don't think it is a big deal. --Timeshifter (talk) 21:30, 5 February 2024 (UTC)
SMcCandlish's reply in a previous thread applies. Sure, you can enter whatever markup you like, but someone may change it to comply with guidelines upon which the community has agreed, and you shouldn't argue with other editors about the specific change. Regarding changing the guidelines so that colons are used as indents instead of list items, based on past community discussions, it doesn't favour this change. Editors prefer that the generated HTML output appropriately reflects the semantics of the page. To do this semantically would require changes to MediaWiki, and there would be a large backwards compatibility problem to resolve. isaacl (talk) 20:21, 5 February 2024 (UTC)
I have no idea what you are talking about concerning the generated HTML effecting anything that matters. I am not arguing. I just don't understand. So until I see how it effects anything that matters I will follow SMcCandlish's advice to ignore it all, and go on as before, and let the gnomes continue fixing stuff that doesn't seem to matter. --Timeshifter (talk) 21:30, 5 February 2024 (UTC)
... fixing stuff that doesn't seem to matter = "Stuff that I'm being told by people who know what they're talking about does matter, but since I don't understand it I'll just stick my fingers in my ears and sing 'lalala' and not worry about the trouble I'm causing my collaborators here nor some of the readers because defiance and lack of collegial cooperation make me happy." Largoplazo (talk) 22:39, 5 February 2024 (UTC)
Note in a collaborative project, it's not necessary for every single volunteer to be convinced regarding project guidelines. It's fine not to understand. But an absence of understanding, or a disagreement regarding rationale doesn't exempt a community member from needing to be co-operative. isaacl (talk) 22:47, 5 February 2024 (UTC)
I am following your advice to follow SMcCandlish's advice. And I am ignoring Largoplazo. I have long ago learned that the "experts" on Wikipedia are sometimes wrong. So unless something makes sense, I don't work in that area. There is plenty of other stuff to do. Wikipedia is done by volunteers. I only volunteer where things makes sense. Or I am helping them make sense. Like on some help pages that interest me. --Timeshifter (talk) 23:05, 5 February 2024 (UTC)
Because the colon approach produces garbage HTML in a situation where the HTML matters, even if it's irrelevant to the page's visual appearance. Nobody ever said producing a proper result doesn't require effort. Largoplazo (talk) 20:51, 5 February 2024 (UTC)
@Timeshifter: in light of the unanimous opposition to this edit, would you please undo it in the spirit of consensus? Best, HouseBlaster (talk · he/him) 20:55, 5 February 2024 (UTC)
Feel free to change it back. --Timeshifter (talk) 21:30, 5 February 2024 (UTC)
See MOS:INDENT. Yes, there is a problem with using a colon as a visual indenter; it only has that effect incidentally, and is the incomplete second half of a description/definition/association list (MOS:DLIST). Abusing : just to generate visual indentation generates bad markup and for screen readers announces a "list" that is not a list. If you need to visually indent something in an article, use {{block indent}} or one of the alternatives. We seem to be stuck with this awful : habit on talk pages, but it shouldn't be done in article content or in internal documentation. The fact that one screen-reader user is used to the effect and not personally bothered by it is immaterial; this is about best practices, not doing poor practice just because we think we can get away with it. Screen readers are also not the only parsers for which it matters; any WP:REUSE of WP content may have completely different CSS that is not choosing to present a DLIST as a boldfaced term with an indented description/definition/association (such display is certainly not required or even suggested by WHATWG or W3C's HTML5 specs; it's quite arbitrary). PS: The fix for talk pages is pretty obvious (stop treating : as <dd> unless it is preceded by ; for <dt> (immediately or with another intervening :), but instead as a CSS-tweaked unordered list item that isn't bulleted, when used in series; or as simply a CSS-indented <span>, when used alone and forming no list of any kind), but the devs have never implemented it for some reason. — SMcCandlish☏¢ 😼 00:02, 6 February 2024 (UTC)
It doesn't affect the Windows screen reader I personally use, JAWS, unless ordered/unordered lists are added into the mix as well, but it does affect NVDA, which is just as commonly used on Windows these days. Graham87 (talk) 07:19, 6 February 2024 (UTC)
Here is a method that allows the overall table header to wrap anywhere as needed. It is using a column header in the wikitext instead of caption wikitext. It is basically a wrapper. Any table can be placed inside without alteration.
Code entered
Output produced
{|class="wikitable mw-collapsible mw-collapsed"|-! A longer table caption needs to wrap for cell phones, etc.|-|{|class="wikitable"! Name !! Score|-| John || 59
|-| Bob || 72
|}|}
A longer table caption needs to wrap for cell phones, etc.
Captions go in the caption element; header information goes in a th element. You're making a pseudo-caption using a hacked th element. This is an accessibility issue. You're using a wrapper table solely for the purpose of collapsing the tale nested inside it. This also is an accessibility issue. --Redrose64 🌹 (talk) 18:14, 6 February 2024 (UTC)
Well, I would like someone with a screen reader to tell me what the screen reader says about it.
Help:Collapsing has various methods to make the top text show up. Sometimes it's text in a data cell. Sometimes it's a row of header cells at the top. Sometimes it's a caption at the top. I have no idea if any of those examples are accessible.
And I didn't write that help page. I just found this method above somewhere, and noticed it solved the wrapping problem in the "Tables with captions" section. So I added it.
Stuff like this is used on user pages too, so it does not have to meet the highest standards. So I wonder if the other collapsible tables there are accessible too. That would be good info to add to the page.
And not all nested tables are bad, or inaccessible. --Timeshifter (talk) 19:44, 6 February 2024 (UTC)
Agreed with Redrose64. Graham87 (talk) 06:23, 7 February 2024 (UTC)
Graham87. Thanks. Is your screen reader able to decipher it at all?
I am wondering if anything on Help:Collapsing is accessible at all. If so, which examples? I would like to indicate that on that help page. I edit a lot table help pages, but I haven't done much on that page. --Timeshifter (talk) 12:13, 7 February 2024 (UTC)
Yes, it's decipherable, but much clunkier with the pseudocaption. this edit made before your comment here has fixed things accessibility-wise as far as I'm concerned ... thanks for that Redrose64. I'm not an HTML expert by any means (just a screen reader user) and this line of questioning (as well as your general approach on this page) is getting rather tedious. Graham87 (talk) 14:42, 7 February 2024 (UTC)
Thanks for the info about the clunkiness. I apologize for any irritation I may have caused.
Are you saying that the other examples on that page are accessible? There are 4 other examples on that help page with pseudocaptions. I didn't add them.
Maybe some others with screen readers can take a look at that.
The ones without captions don't use pseudocaptions in the same sense. They're OK I guess to *me* ... but don't take that as an indication of anything. I don't think this conversation is worth taking any further. Graham87 (talk) 17:12, 7 February 2024 (UTC)
OK. I think I see what you and Redrose64 are talking about now. All of the examples on that page are single tables. And the top text that is showing is the same as if it were not a collapsible table. So they are not pseudo-anything.
The example I tried to add only had the top text of the wrapping table. Not of the nested table inside of it. And it is clunky and inaccessible.
In contrast to the nested tables used for the wikitext/results pairs. Those are an example of accessible nested tables according to this talk section higher up: #Are these nested tables accessible?
This discussion is related to MOS:COLOR, specifically to the bit that says do not use colored text or background unless its status is also indicated using another method, such as an accessible symbol matched to a legend, or footnote labels. Comments are welcome over there. – Jonesey95 (talk) 01:46, 9 February 2024 (UTC)
You are invited to join the discussion at Wikipedia talk:WikiProject Film § Awards and accessibility under Vector 2022. RunningTiger123 (talk) 19:04, 3 February 2023 (UTC)
.svg)
19:54, 3 October 2023 (UTC)
