This is an archive of past discussions on Wikipedia:Manual of Style. 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.
Latest comment: 1 year ago2 comments2 people in discussion
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.
Latest comment: 1 year ago2 comments2 people in discussion
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. Graham8714:09, 4 April 2023 (UTC)
Latest comment: 1 year ago6 comments3 people in discussion
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. Graham8702:33, 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. Graham8715:43, 11 June 2023 (UTC)
Latest comment: 1 year ago4 comments2 people in discussion
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. Graham8715:58, 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)
Can we deprecate the advice on typographic symbols?
Latest comment: 1 year ago7 comments6 people in discussion
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, 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"
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)
Latest comment: 1 year ago3 comments3 people in discussion
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. Graham8714:36, 28 July 2023 (UTC)
Latest comment: 1 year ago14 comments8 people in discussion
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
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.
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. Graham8709: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. Graham8704:44, 11 August 2023 (UTC)
Fractions in category names
Latest comment: 1 year ago1 comment1 person in discussion
Latest comment: 1 year ago2 comments2 people in discussion
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)
Latest comment: 1 year ago1 comment1 person in discussion
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
Latest comment: 1 year ago10 comments4 people in discussion
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? ~TPW13: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. ~TPW18: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'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. ~TPW13:46, 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. ~TPW13: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)
Re recent edit summary about font size
Latest comment: 1 year ago3 comments3 people in discussion
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
Latest comment: 1 year ago8 comments7 people in discussion
Avoid placing images on the left hand side as a consistent left margin makes reading easier.
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.
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)
Latest comment: 1 year ago19 comments7 people in discussion
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.
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)
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.
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)
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}}talk22:54, 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)
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
Latest comment: 1 year ago7 comments7 people in discussion
Making redundant table captions screen-reader-only
Latest comment: 11 months ago41 comments7 people in discussion
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? Ss11200: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. Ss11202: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❯❯❯talk03: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. Ss11205: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)
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. Ss11207: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. Ss11208: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. Ss11210: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❯❯❯talk20: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. Ss11201: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. Ss11204:35, 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❯❯❯talk22: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. Ss11203: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)
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❯❯❯talk09: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. Ss11213: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
Latest comment: 11 months ago1 comment1 person in discussion
Latest comment: 10 months ago2 comments2 people in discussion
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
Latest comment: 10 months ago1 comment1 person in discussion
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.
Latest comment: 10 months ago3 comments2 people in discussion
@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)
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)
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äper13: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?
Latest comment: 10 months ago28 comments6 people in discussion
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.
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.
@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:
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)
Latest comment: 9 months ago15 comments7 people in discussion
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]
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)
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: 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)
Colon versus margin
Latest comment: 9 months ago17 comments6 people in discussion
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)
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)
Is this collapsible table accessible?
Latest comment: 9 months ago9 comments3 people in discussion
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.
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?
Latest comment: 9 months ago1 comment1 person in discussion
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)
Strong tags
Latest comment: 9 months ago24 comments11 people in discussion
Hi! It has been my impression that in an ideal world, <strong>...</strong> should be used used instead of '''...''' to indicate bold emphasis. Is that correct, or can they be used interchangeably? HouseBlaster (talk · he/him) 01:24, 1 February 2024 (UTC)
My question is to screen reader users. Does the screen reader verbally announce the beginning and end of bolded text? Is that annoying? As a sighted reader I find that bolded text is helpful, but not essential. But if my reading of the text was interrupted by some audio or flashing light or whatever, then I would be annoyed.
Is it only certain bolded text that is announced by the screen reader? <strong>...</strong> versus '''...'''
Are top headers in tables announced as the bolded text that they are? Can that be turned off? What about row headers that are bolded (if not using class=plainrowheaders). Are these italics announced?
They don't read out any attributes like that. As the guideline says (and my experience confirms), "By default, most screen readers do not indicate presentational text attributes (bold, italic, underline, monospace, strikethrough) or even semantic text attributes (emphasis, importance, text deletion)". Graham87 (talk) 07:50, 1 February 2024 (UTC)
Column and Row headers are semantic and are represented (well mostly) by screenreaders, but the bolding they have is purely presentational. —TheDJ (talk • contribs) 09:17, 1 February 2024 (UTC)
The Wikicode that includes '''...''' isn't what's sent to the browser. It's converted to HTML, as <b>...</b>. So it's a b element rather than a strong element, but it certainly isn't '''. The point of Wikicode is that it take much less labor to write than does HTML, but it's HTML that gets sent to the browser. Largoplazo (talk) 11:13, 1 February 2024 (UTC)
I believe the original poster wasn't under the impression that the wikitext markup was being sent to the browser. Conventional web best practice is to use semantic markup rather than presentation-specific markup (with presentation being handled by CSS). The reality though is that elements such as <b> and <i> are widely prevalent on the web, so for better or worse, assistive technologies have to take this into account. isaacl (talk) 17:34, 1 February 2024 (UTC)
If it's semantic emphasis, use <strong>...</strong> or the template wrapper {{strong}}, but per MOS:BOLD this should very rarely be done; use <em>...</em> or {{em}} in most cases instead. Whether screen readers right this second support this semantic markup very well is immaterial; it exists and is well-defined as serving this semantic purpose, and support will get better over time. What's never going to be helpful is using ''...'' (equals <i>...</i>), or '''...''' (equals <b>...</b>) where semantic emphasis is intended, because that is purely visual formatting with no semantic implications (e.g. italics around foreign terms or book titles, or boldface to mimic the bold keyword in a directly quoted definition that was boldfaced that way in the original source). Screen readers will ignore that non-semantic markup on purpose and are never going to change in that regard.
Technically speaking, <i>...</i> is directly equivalent to <span style="font-style: italic;">...</span>, and <b>...</b> is directly equivalent to <span style="font-weight: bold;">...</span>, with the short tags grudgingly retained, despite failing the separation of content and presentation, simply because their use is too convenient and ingrained. Use of these elements has no implication of importance or stress/emphasis. For more details, see the i and b element entries in the HTML5 spec [4], and contrast them with the em and strong elements [5]. According to the spec, nesting multiple instances increases stress level, though it is dubious whether any real-world applications support this yet (e.g. by increasing volume and/or pitch).
PS: Use of bold for pseudoheadings to avoid ToC entries should use '''...''' (equals <b>...</b>), since even real headings simply have boldface applied by CSS, not semantic stress. Using strong for that purpose would imply that the pseudoheading was the most or one of the most important things on the page, which is rather the opposite of the intent. And definitely don't abuse ; markup for this, per MOS:DLIST; that creates a bogus definition/description/association list, that has a term (the boldfaced item) but no definition/description/association. — SMcCandlish☏¢ 😼 10:11, 2 February 2024 (UTC)
MOS:BOLD says bolding should rarely be done. Am I correct that when bolding is done for emphasis, it should be done with <strong>...</strong>, not '''...'''?HouseBlaster (talk · he/him) 03:11, 4 February 2024 (UTC)
What purpose do strong tags really serve? The default settings for screen readers is to ignore it. Are we waiting for a future utopian semantic web that will probably never arrive? AI large language models seem to be working fine even though the vast majority of the web is not using semantic web coding. I notice you using em tags in your reply. Are we really going to encourage such preciousness for something I have yet to see serving any useful purpose? --Timeshifter (talk) 03:19, 4 February 2024 (UTC)
First, that is moving the goalposts. The purpose it serves is separation of presentation and content. AI large language models seem to be working fine even though the vast majority of the web is not using semantic web coding is irrelevant. AI also seems to be working just fine with all the typos on Wikipedia, but that doesn't mean we should encourage typos. I use em tags because they are the semantic markup for emphasis.HouseBlaster (talk · he/him) 03:31, 4 February 2024 (UTC)
If they serve no purpose, then why bother? People reading Wikipedia still see bolding and italics either way. Screen readers ignore em and strong tags in their default settings. AI works fine without it. Why do you even care? Very few people are going to follow you in this crusade. But you will annoy a lot of people by telling them they must use em and strong tags for basic article editing. Wikis were made for ease of use, and to not need the more arcane coding of HTML, etc.. We are trying to keep new editors, not drive them away with bizarre coding demands that serve no purpose. --Timeshifter (talk) 03:41, 4 February 2024 (UTC)
Please do not personalize the dispute. I just explained the purpose it serves: separation of presentation and content. I am not forcing you to avoid using '''...'''. But I am going to fix incorrect use of presentational markup for semantic emphasis, just like I would fix a typo. Rather than go back and forth, I will wait for others to respond because we are not going to convince one another.HouseBlaster (talk · he/him) 03:49, 4 February 2024 (UTC)
This principle is not a rigid guideline, but serves more as best practice for keeping appearance and structure separate. In many cases, the design and development aspects of a project are performed by different people, so keeping both aspects separated ensures both initial production accountability and later maintenance simplification, as in the don't repeat yourself (DRY) principle.
That is mainly about using external stylesheets over inline CSS. And so on.
It is not about applying em or strong tags on Wikipedia. They are applied individually, and they serve no special presentation purpose on Wikipedia, or in screen readers at default setting. The result looks exactly the same as editing-toolbar-applied bolding or italics. You have yet to show me how it serves any purpose in the real world. --Timeshifter (talk) 04:35, 4 February 2024 (UTC)
Timeshifter, the fact that you don't like to bother with the correct markup, and are impatient for more practical real-world utility for it, is immaterial. No one is required to "obey" the MoS to add material; all that is required is you not go around changing compliant markup to non-compliant markup or get in fights with people making noncompliant markup be compliant. If you just use bare/basic bold every time you add something new and some of it should be using strong, someone else will fix it later. MoS is primarily a WP:GNOME cleanup manual (and to the extent it's not, it a dispute-resolution manual, which resolves to "just follow the guideline") — SMcCandlish☏¢ 😼 00:46, 5 February 2024 (UTC)
It is not the first time I have seen a MOS or other guideline that serves absolutely no purpose. But this is the page for MOS accessibility, and so this is the page to discuss it. So you agree with me that it serves no accessibility purpose. Then the quideline at MOS:BOLD needs to be changed. It says: "This way, the words can stand out for text to speech and other accessibility softwares." That needs to be removed or clarified. Clarified with a link to the Graham87 diff that says the default settings for screen readers ignore it. That way, there will be fewer editors wasting their time adding useless strong tags. --Timeshifter (talk) 11:15, 5 February 2024 (UTC)
Thanks Graham87. I suggest putting after semantic markup: (part of the semantic web, a pipe dream). And after "which may be used by screen readers and other accessibility software": (though nobody has been found using screen readers, etc. this way on Wikipedia, so don't waste your time adding strong and em tags. And it goes against making wiki coding simpler, not harder). But I think I may bow out of this discussion for awhile. There was something else that was spread around various help pages for years that was of a similar vaporware nature. I can't remember now what it was, but it disappeared. --Timeshifter (talk) 16:13, 5 February 2024 (UTC)
HouseBlaster. I will not change your strong tags back to regular bolding, now that this discussion has sadly resolved in the favor of your current point of view. If you want to waste your time on this useless activity, then knock yourself out. In fact, after you completely convert all bolding to strong tags on a few help pages, you will have annoyed enough editors that this vaporware of the semantic web will be seen as contradictory to the simplicity that wikis were created for. Or maybe the Mediawiki developers will convert all bolding to strong tags in the HTML. And that way we can continue to use the much simpler method of bolding in the wikitext editing toolbar. --Timeshifter (talk) 16:23, 5 February 2024 (UTC)
<strong> is used for bolding with emphasis and <b> is used for bolding without emphasis (Mediawiki changes ''' to <b>). In the Sticky header template doc page example, if the intent is to emphasize the sentence, use <strong>, and if the intent is not to emphasize the sentence, don't use any bolding at all. I see no case where we'd use <b> (aka ''') for that sentence. Levivich (talk) 19:34, 5 February 2024 (UTC)
The discussion here has come up at a policy page, in WT:Banning policy#Semantic markup. Whether or not the way that the vast majority of editors edit presents an actual accessibility problem is something that I don't have the expertise to really understand, but I think it is likely that there will be a lot of pushback against implementing such changes, without first getting widespread community buy-in. --Tryptofish (talk) 21:25, 12 February 2024 (UTC)
When are tables an accessibility problem?
Latest comment: 8 months ago83 comments10 people in discussion
I'm involved in a dispute where Thumperward has removed tabular versions of information in Endianness arguing that a written description is adequate and the tables are an accessibility problem. There are a few other issues in play but please refer to the end of this discussion for the main points.
Is there really an accessibility problem with standard tables like this? Do we really discourage using tables where prose can be used instead or is it OK to include both appreciating that a bit of repetition in different formats is helpful for many readers. ~Kvng (talk) 15:58, 1 February 2024 (UTC)
If the problem is HTML vs. Wiki I think I've already proposed we can do any necessary behind-the-scenes formatting changes to address accessibility technical issues. Tables like these are used frequently to illustrate data layout in packets and memory e.g. User_Datagram_Protocol#UDP_datagram_structure. Would you propose to remove these too? ~Kvng (talk) 17:21, 1 February 2024 (UTC)
The columns are successive byte addresses, and the rows show different interpretations of the stored bytes. Appropriate headings for the columns and rows should be able to clarify this. isaacl (talk) 18:57, 1 February 2024 (UTC)
Tables are in fact commonly used in format specifications to describe how the bits and bytes are laid out (and not to describe the appearance of the data being stored). isaacl (talk) 08:59, 2 February 2024 (UTC)
It's a perfectly good visual representation of the concept that it illustrates, but in web terms it's awful because in HTML terms it's badly constructed and because it's inaccessible by screenreaders. The only options I can think of are
Describe the matchup between bytes and words very well in the text and then, on the table tag, add an aria-label stating "A table providing a purely visual representation of the ... explained above." But that's still off-putting use of HTML and still subjects the screenreader user to sitting through the mumbo-jumbo to get to what's after it. Though maybe that could be resolve by supplying a screenreader-friendly Skip link.
Replace it with an image and supply suitable alt text. After all, nobody benefits from it being cobbled out of HTML.
Anything that makes an article clearer through illustration or tables, or combinations thereof, are a good thing in my mind.
If the table-diagram would serve this purpose as an image, but unfriendly table coding is used instead, then I think your idea is good: "a screenreader-friendly Skip link."
Table coding may be easier to edit for many people than image editors. So whatever is easiest. If there is a choice use the better illustrative final result. That can change. Put the various versions on the article talk page so others can further improve either format (image or table coding).
I think with the addition of appropriate column and row headings, the meaning of each cell will be discernable. It's not a lot different than how protocols or file formats are described in specification documents, and those use tables. (For a Wikipedia example, see Transmission Control Protocol § TCP segment structure.) isaacl (talk) 23:37, 1 February 2024 (UTC)
I'm no expert but it seems unlikely to me that headings will make any difference. It's the visual experience of the juxtaposition that makes the illustration effective. But, for sighted readers, it's a supplement, not the primary explanation, anyway. Graham87, who is blind, didn't seem hopeful in his comment above. Largoplazo (talk) 23:46, 1 February 2024 (UTC)
As I alluded to, endian layouts in protocols have long been displayed in tables. It's much more effective than describing data formats in prose. isaacl (talk) 00:01, 2 February 2024 (UTC)
All commonly used screen readers have keystrokes/actions for moving to the end of a table, moving to the next table, etc. We don't need a skip link. Graham87 (talk) 05:14, 2 February 2024 (UTC)
Nobody is arguing that ignoring the needs of others is not more efficient. Technical articles full of this sort of thing are usually dreadful anyway, and that especially applies to our networking articles (which are written exclusively by and for people who already understand the subject). Chris Cunningham (user:thumperward) (talk) 07:17, 2 February 2024 (UTC)
@Kvng, if the idea of constructing a vector diagram seems daunting, you could make a screenshot of the "ASCII art" and upload that as a bitmap image. It'll still be as useless as any other photo to people using screen readers, but the objections about misusing table formatting would evaporate.
Kvng, HTML elements have defined semantics that differing presentation modes for documents (such as screen readers) are supposed to be able to rely on or expect. A table in HTML is supposed to be just that. While any accessible software inevitably has some work dedicated to cleaning up behind the scenes when documents don't adhere to the standard, it is still broadly an issue for accessibility—even if considered to be more or less so according to how concrete or obvious it is to any given individual. — Remsense诉00:24, 2 February 2024 (UTC)
I don't understand MOS:LTAB. I don't think just the addition of role=presentation will warn off a screen reader user to the equivalent of "there be dragons here", and so ignore this. I looked online elsewhere about it, and can't see how it would act as "a screenreader-friendly Skip link."
As a last resort, a screenshot can be taken as previously suggested, and uploaded to the Commons. I use freeware Irfanview for such stuff since it can save the image as a compressed PNG image (for low kilobytes). --Timeshifter (talk) 01:48, 2 February 2024 (UTC)
Jroberson108 and others. I don't understand that stuff. Can you tell me if there is a way to tell a screen reader that an upcoming table will not be accessible? Graham87 said: "All commonly used screen readers have keystrokes/actions for moving to the end of a table, moving to the next table, etc. We don't need a skip link." But the screen reader user shouldn't have to waste time trying to figure out an inaccessible table before giving up and moving to the end of the table. They should be warned. I guess some text could be added in front of the table such as "Inaccessible table". A way is needed to present that text just to the screen reader user. I don't think it is a good idea to convert tables to screenshots unless absolutely necessary. Having to upload a new version of a table screenshot over the old version for every little change is more work. --Timeshifter (talk) 13:26, 2 February 2024 (UTC)
No, that would be extremely jarring and would be ramming an opinion down people's throats. Maybe *some* screen reader users might find it marginally useful, for some reason (especially if they're visually impaired and using a screen reader along with a screen magnifier, say). There is some advice about making a screen reader detect a table as a layout table rather than a data table in the accessibility guideline, but that really wouldn't help here. Graham87 (talk) 15:15, 2 February 2024 (UTC)
I'm fine with "screenshot with appropriate accompanying text" as a solution here, though to be honest I tend to skip the screenshot. The question is not really about what alternatives are available so much as clarifying that the examples presented are not considered an accessible way to present the information, which this discussion already seems to have validated. Chris Cunningham (user:thumperward) (talk) 07:05, 2 February 2024 (UTC)
I would agree with doing these as images, since they really are illustrations cobbled together with HTML markup and are not actually data tables. This could be done using a sandbox page to fine-tune the result and get the best screen-shootable version (perhaps by making it substantially larger, so the resulting image is higher resolution than than a typical wiki table at an average font size). — SMcCandlish☏¢ 😼 09:33, 2 February 2024 (UTC)
Rather than using an image, I think it would be better to convey the information in a data table. For instance:
Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11
That removes the problem of the abuse of semantic HTML. But re accessibility, won't a screen reader read this is something like "byte offset 1 8-bit value 0bh 16-bit little-endian value 0a0bh byte offset 1 8-bit value 0ah 16-bit little-endian value 0a0bh" etc.? It seems as though it will fail to convey the point it's meant to convey.
I don't know for sure, but it always strikes me that the use of spans for anything other than creating a header hierarchy from left to right (or right to left in rtl scripts) or top down is inaccessible and, in an actual data table (though I don't see it as a problem here), pointless. Largoplazo (talk) 18:07, 2 February 2024 (UTC)
A horizontal layout would probably make the relationships more clear for screen readers reading in the inline direction:
Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11
I actually like the first one better, but I don't know exactly why ... screen readers also have table navigation commands for moving by row or column. Graham87 (talk) 06:45, 3 February 2024 (UTC)
I'm back. I don't see discussion of Thumperward's assertion that the tables should be removed because the layout is already described in prose. Instead, there are suggestions about how these can be composed or rendered in a more screen-reader-friendly way. I learned that screen readers have a skip feature so if these tables aren't helping, they aren't too much in the way.
There was a suggestion to render these as bitmap or vector images and use ALT to describe them. It is easier for editors to maintain the table markup. Is there a way to add an ALT to a whole table? ~Kvng (talk) 23:48, 4 February 2024 (UTC)
Not really, anymore, since the summary attribute is obsolete in HTML5, per Help:Table § Captions and summaries. It's possible to use {{sronly}} with a caption though to make all or parter of it only read by screen readers. But in this case, one of the above two examples of a fixed-up version of the table would suffice. I'd say. Graham87 (talk) 03:33, 5 February 2024 (UTC)
There is broad recognition that these tables are not useful to those using screen readers. It has been suggested that the tables be replaced with images but this would not help editors and there is not a consensus that this would help readers. I don't see anyone supporting Thumperward's assertion that tables (or images) should be removed if the material is already explained in prose. In general, the Wikipedia way is to improve, not delete problematic content so I am inclined to revert Thumperward's deletions while anyone interested works on improving this. ~Kvng (talk) 21:55, 9 February 2024 (UTC)–
The point I was trying to make is it is not clear that converting the tables to images would help readers. Sighted readers would see the same thing. Those using screen readers would either skip an image or a table; neither seem to be of help to them. ~Kvng (talk) 03:14, 10 February 2024 (UTC)
And I've said several times that I have no problem with converting these tables to images and including them that way, with adequate captions and alt text. Indeed there are already comparable illustrations of this sort available. If you're looking for a compromise with broad consensus, then there it is. Declaring an intent to simply revert to your preferred version is quite different. Chris Cunningham (user:thumperward) (talk) 12:06, 10 February 2024 (UTC)
@Thumperward, I'm not looking for compromise with you personally, we're seeking WP:CONSENSUS among involved editors. Do you agree that images are more difficult for editors to maintain? If so or in any case, I assume you believe this potential disadvantage is outweighed by an accessibility improvement. I don't have screen reader experience but Graham87 has reported that tables and images can both be readily skipped when using a screen reader. ~Kvng (talk) 13:48, 10 February 2024 (UTC)
@Timeshifter clearly there's a tradeoff to be made here between accessibility and maintainability. I don't see any discussion of converting tables to images in the MOS page you link (Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Images_and_color is about images in tables, not images of tables). I have not seen this conversion done in practice by editors. I have seen the reverse with editors justifying the table as more easily maintained (and no discussion of accessibility). ~Kvng (talk) 14:19, 10 February 2024 (UTC)
That is about icons mostly. That is not about what we are talking about.
About a table image: It just takes a little longer with an image if you decide to change it. But once an image is the way you want it to be, then there is no more work involved. So do all your work in a personal sandbox. I have hundreds of sandboxes. I keep the ones that are linked to discussions. See my user page: User:Timeshifter#Archives, subpages, etc.. Open the subpage index. If you keep a sandbox for each table, then it is easier to come back to it later, and do more work on it. Months, even years later. Screenshot it, and upload it over the old version. But it is even easier to just learn how to make the table accessible, and then everybody is happy. --Timeshifter (talk) 14:39, 10 February 2024 (UTC)
I want everybody to be happy but there doesn't seem to be consensus (at least not in this discussion) about what it takes to make these tables accessible. ~Kvng (talk) 14:48, 10 February 2024 (UTC)
You can't. HTML tables are designed to present tabular data (it's, erm, in the name) and their misuse to draw boxes is discouraged. That's the whole story. Nobody has said otherwise.
With regards to maintainability: if these tables were being regularly edited for some reason then that might be something which would warrant some other approach (maybe using Lua to dynamically regenerate them from wikicode). But they aren't: these diagrams are rarely edited (what with them being so finicky) and most of them were put in place well over a decade ago and left to rot. Another reason to bin them, as including complicated code in articles discourages inexpert readers from improving them. Chris Cunningham (user:thumperward) (talk) 22:40, 10 February 2024 (UTC)
I guess you can try to make a case for no need for maintenance here but then you go on to say they have been "left to rot" which implies otherwise. In any case, there are many other similar tables in networking and computing articles where more maintenance is performed. Do we do some with tables and others with images based on anticipated maintenance needs? IME trying to anticipate future changes is folly.
I don't like the idea of giving up and deleting things because it's too hard to do a good job for both normal readers and screen readers. That can't be right, can it? ~Kvng (talk) 02:27, 11 February 2024 (UTC)
@Kvng: All I said was "All commonly used screen readers have keystrokes/actions for moving to the end of a table, moving to the next table, etc." As it happens images aren't hard to skip either, but I thought that was worth clarifying. Graham87 (talk) 16:02, 10 February 2024 (UTC)
This is being deliberately obtuse. Multiple people have highlighted the problems with table diagrams. Nobody has supported your assertion that they are a positive improvement. You're trying to make articles worse for the sake of winning an argument on a technicality. Don't do that. Chris Cunningham (user:thumperward) (talk) 22:05, 9 February 2024 (UTC)
Thumperward. Isaacl found a way to improve some tables enough to get Graham87's approval.
Several people said tables like these help illustrate points in the related articles.
And almost everybody says that when tables can't be made accessible, then images can be used.
@Thumperward, at your request, I've spent a lot of time trying to engage others and work through this one issue productively with you. Please don't assume I have a goal other than to improve Endianess (and learn about accessibility issues). ~Kvng (talk) 03:18, 10 February 2024 (UTC)
I'm not sure to what you are referring when you say "these tables". I disagree that there is broad recognition that tables with appropriate column and row headings are not useful to those using screen readers. I think presenting endian information in tables is natural for both those who can see the table layout and those who can hear it being read, and thus tables would be preferable to images. isaacl (talk) 22:58, 9 February 2024 (UTC)
@Isaacl I'm sorry if I missed that point. Are you saying adding your proposed headings somehow render these legible by a screen reader? Has anyone (else) tested this? ~Kvng (talk) 03:23, 10 February 2024 (UTC)
I'm not exactly sure when you say "legible by a screen reader" if you mean whether the screen reader will read the table, or if someone using a screen reader will be able to understand what they hear. Screen readers will read tables, but if the table doesn't have headings, the screen reader won't be able to provide this context when reading a cell. With headings, it can announce this info when reading a cell. Yes, the examples I provided have been tested by someone, as you can see in the earlier discussion. Part of the point of having accessibility guidelines, though, is that following them will generally produce useful results, without having to continually round up test groups (which as mentioned in another thread, is tedious if the same person is going to get polled for every single possibility). isaacl (talk) 05:12, 10 February 2024 (UTC)
@Isaacl, we're trying to determine which is more accessible, images or tables. A screen reader would give caption and alt text for an image. Would it give something better than that for tables with your proposed headings? ~Kvng (talk) 13:54, 10 February 2024 (UTC)
A table provides interactive navigation of the data: a user can move from cell to cell, with the screen reader announcing the position (including heading info) and the cell contents. It has a caption, too. Alternate text for an image provides one static message, and would not allow the user to explore the interpretation of a given byte or pair of bytes at a particular byte offset. isaacl (talk) 17:55, 10 February 2024 (UTC)
Tables also generally scale better than images with using different page zoom levels, as the browser can use larger or smaller font sizes instead of using an image resizing algorithm, so this is more accessible for those who change the zoom level. Although it's not a significant issue for this table, browsers can alter the table layout as appropriate with browser window size changes, which also improves legibility and thus accessibility. isaacl (talk) 18:08, 10 February 2024 (UTC)
Kvng. See: Talk:List of countries by intentional homicide rate. See the note at the top: "Note: Table updating info: /LibreOffice Calc instructions and /Excel instructions." Those are talk subpage links. You might use talk subpages to park tables to work on continuously over the years. Tables that are accessible can be copied to the article. Screenshots can be taken of inaccessible ones. Tables that are neither inaccessible nor understandable can stay in the subpage for further work by whoever is interested over the years. This method is not effected by talk page churn and archiving. Stuff stays in place. You can have multiple subpages. --Timeshifter (talk) 01:12, 13 February 2024 (UTC)
@Timeshifter: If I were you I'd put such a note in a template like {{notice}} (or whatever looks good), just so semi-automated/automated scripts like AWB general fixes don't add an "Untitled" heading to them. Having non-template text before the first header of a talk page is highly non-standard. Graham87 (talk) 09:52, 13 February 2024 (UTC)
Thanks Graham87. I tried it but it blends in too well with the wall of other talk table/banners, so it is not noticed. I will be using it elsewhere though. I haven't had any problems with WP:AWB since it is manually operated, and it is obvious that the note needs no change. I haven't seen a problem on multiple talk pages. I would like a template like Template:See also but for notes. Its indentation doesn't seem to bother people using screen readers, I believe. And it has no background color, and doesn't take up so much space like {{notice}}. --Timeshifter (talk) 20:15, 13 February 2024 (UTC)
Graham87. Ah yes, the upcoming battles against our AI bot overlords globally in auto mode. Just kidding. I guess I will take my chances. They haven't covered the talk pages I am talking about in auto mode in any detrimental way yet. And I can always fix it if they do. I found this related info: Help:Talk pages#Subpages and archiving.
@Timeshifter: You're not going to live forever and you won't be on Wikipedia forever either. I would strongly recommend using *some* sort of template to note the subpages for the sake of long-term standardisation. Also, that help page you linked contains some really old cobwebs ... including the bit you were probably referring to which I've boldly removed. I referred back to this talk page at Help talk:Talk pages#Note about subpages. This conversation is probably getting way off-topic for here. Graham87 (talk) 17:01, 14 February 2024 (UTC)
FWIW I think using {{notice}} is a good and appropriate suggestion. What you have there now is likely to get swallowed at some point by an archiver or editor doing cleanup. ~Kvng (talk) 00:43, 15 February 2024 (UTC)
Using subpages is a good suggestion if this is the way it needs to go. This would help current and sufficently determined editors make changes. It doesn't quite fulfill the "Encyclopedia anyone can edit" objective. ~Kvng (talk) 15:00, 13 February 2024 (UTC)
Correct me if I've misread but I don't see any sustained support for not including these tables. Although it remains to be decided whether they should be rendered as images or HTML tables, I think it is now appropriate to restore the tables to Endianness while we work on accessibility improvements. ~Kvng (talk) 15:06, 13 February 2024 (UTC)
I've already presented how to make one of the tables accessible by adding a caption and headings with scope attributes. Including these will bring the tables into alignment with best practices for accessibility. isaacl (talk) 18:44, 13 February 2024 (UTC)
I'm honestly not entirely opposed to your suggestion - it does indeed solve the issue by making this a tabular display of content instead of an illustration. Whether it truly clarifies anything in the article is another matter, but that's more of a style issue. Chris Cunningham (user:thumperward) (talk) 08:53, 15 February 2024 (UTC)
Bad-faith reverts
This was very obviously not a result of the above discussion, but instead a lawyerish move to win an argument based on an obtuse interpretation of what is and is not forbidden. The result is terrible and should be removed again. Chris Cunningham (user:thumperward) (talk) 23:47, 17 February 2024 (UTC)
The single conclusion which cannot possibly be drawn is "the table was fine as-is, put it back in". Literally nobody except you has advanced this.
Given that this is a style guide discussion page and not a courtroom there was not a single decision that was rounded on by everyone. However, the following positions were all given weight:
Tables should not be used merely for style;
If data is being presented in a table, then the use of features such as headings, labels and captions is strongly encouraged;
For purely illustrative purposes, an image produces results which are no less accessible than tables full of line art.
In the interest of compromise (and let's be clear here: I did this twice, whereas your "compromise" was to revert directly to your preferred version from pre-discussion), I made two suggestions: either use an image, or use the tabular format Isaacl suggested here. Either would be a significant improvement. Chris Cunningham (user:thumperward) (talk) 11:16, 18 February 2024 (UTC)
isaacl has since improved the tables after my revert. I beleive we're where we want to be for this table. I encourage you to hep us get there with the others. It was always my intent that the tables be improved. I said above I think it is now appropriate to restore the tables to Endianness while we work on accessibility improvements. My idea was it would be easier to improve incrementally from what you deleted than to recreate from scratch. isaacl seems to have misunderstood this too and I'm sorry if I wasn't clear. ~Kvng (talk) 13:58, 18 February 2024 (UTC)
No, I fully understood what you proposed. I responded on your talk page with my view that you shouldn't revert back to the previous version since the discussion had already been started on how to improve the tables. Multiple people have pointed out in this discussion the advantages of having headings. Each time you spoke about restoring the previous version, I highlighted how instead a more accessible version can be added. I'm disappointed you chose to proceed with your revert. isaacl (talk) 18:16, 18 February 2024 (UTC)
That discussion was two weeks ago. It was good advice when this discussion was in its early stages and I heeded it. You said I favour seeing what consensus can be found before changing the article again. Twice above I asked if we had consensus and when it seemed we did, I waited another couple of days before taking first steps to implementing it. Again, it was never my intent or position that we should restore the removed material and leave it at that. I restored the material so that you could apply your improvements to it. ~Kvng (talk) 18:41, 18 February 2024 (UTC)
Not sure why you keep repeating your intent; as I said, I understood fully. You participated in the discussion regarding the accessibility advantages, and I created the wikitext markup for you so you could have easily copied it over. Twice after you asked about reverting to the original version I pointed out the accessible version. It would have been ideal to have worked collaboratively on improving the table, which you said you wanted to do, rather than not making use of the provided improvements. isaacl (talk) 22:57, 18 February 2024 (UTC)
So you both are unhappy I reverted and then we improved the tables rather than (me?) adding fresh improved ones based on isaacl's work. Sorry about that. There is still another set of tables that needs to be restored/added. Thumperward has indicated that he's unwilling to help with this. How do we want to proceed? ~Kvng (talk) 14:29, 19 February 2024 (UTC)
Note I do not support your re-adding the previous version of the table into the article. This remains the case even if you post about it again and I don't respond. I'm not sure of the best way to discuss how character bytes packed into an integer are affected. The heading "Byte addressing" doesn't seem apt. At some point I might try to consider ways to improve the current text. isaacl (talk) 19:02, 19 February 2024 (UTC)
Kvng and Isaacl. In the meantime the tables can be parked in talk subpages until they are made accessible and understandable. I found that the generic hatnote template works for notes at the top of talk pages. Template:Hatnote.Graham87 or others, please tell me if the following notes are accessible. The links work when the notes are looked at from the talk pages.
The subpage acts as a sandbox for experimentation, continual improvement, links, notes, discussion, etc.. Editors can get up to speed faster if they can go to one place. Stuff rolls off talk pages. Editors change. --Timeshifter (talk) 18:29, 26 February 2024 (UTC)
Future editors are not bound by what was done in the past. They can determine from scratch if a different presentation of the data would offer greater advantages than the current prose. Changing editors is good for new ideas. isaacl (talk) 18:43, 26 February 2024 (UTC)
I agree. Editors can use, or not use, what was done in the past. That is the way I operate. It is nice to know what has been tried already, too. Why reinvent the wheel. Saves a lot of time and grief. Makes it easier to try out new ideas. And/or to fix what was broken. If someone parks a table in a subpage, then someone else, even years later, may be able to fix it. I fix and update lots of tables. --Timeshifter (talk) 20:23, 26 February 2024 (UTC)
Kvng said he might use this idea. Graham87 asked for a template for these subpage notes. You asked that Kvng not repost inaccessible tables. Thumperward did not want bad-faith reverts. This allows Kvng to save those tables without reposting them. Moving this thread elsewhere would remove this solution from other editors with the same problem. --Timeshifter (talk) 14:16, 27 February 2024 (UTC)
This particular subsection is about one article. You've asked for feedback on some changes you made to other talk pages, thus hijacking this thread. Please separate this request into a separate subsection. isaacl (talk) 17:56, 27 February 2024 (UTC)
Template:Collapse top, and Template:Collapse bottom
Latest comment: 8 months ago8 comments4 people in discussion
The {{collapse top}}/{{collapse bottom}} templates use a div element as the fundamental construct. This is completely different from misusing a table to achieve a similar effect, i.e. collapsing the enclosed content. Per the HTML 5.2 spec, The <div> element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements. - in other words, a div element has no inherent semantic meaning; it is a convenient means for delimiting a block of page content. --Redrose64 🌹 (talk) 23:17, 7 February 2024 (UTC)
Thanks. I wish the collapsed box aligned to the left. I don't see a parameter for doing that. Unless I am missing something. I did find a width parameter. And a text alignment parameter.
Unfortunately, the width parameter is not a max-width. It does not wrap.
I did find a weird indent= parameter. By using negative percents or em units one can move the box to the left. But if set wrong the box extends off the screen to the left. So it is an accessible collapsible box that needs work. I may take this up on that template's talk page. I need to look at this on other monitors to see if it is aligned approximately the same. On my main monitor it currently lines up even with the text on the talk page. But when I increase my text size via the browser zoom setting the alignment changes. As does lessening the browser window size. Both push the box off the page to the left.
A longer title needs to wrap for mobile portrait view, etc.. More text to test wrapping.
" I wish the collapsed box aligned to the left" you mean instead of being fullwidth, you want it to be as wide as the title and left align ? —TheDJ (talk • contribs) 13:10, 8 February 2024 (UTC)
Yes, exactly. And I want the title to wrap as it does now when no width parameter is added.
I am on a bigger monitor now, and the box is a few inches away from the left side. Whereas on the smaller monitor I had the box lined up with the left side of the text. Using the indent= parameter.--Timeshifter (talk) 14:27, 8 February 2024 (UTC)
This template is also only for user pages. The heading wraps in default mode. It has a "table-width" parameter that can use em units, percents, etc.. The heading width set by em units will not wrap.
The heading width set by a percent will wrap in narrower screens and browser widths. Still need a template with a width that exactly matches header text width, and wraps. Percent widths will not look the same in different tablet and desktop screen resolutions. In some the heading will be on one line, and in others it will be on 2 lines. A "max-width" setting is needed. But this template is better than the previous one for setting header width. If it is accessible.
A longer title needs to wrap for mobile portrait view, etc.. More text to test wrapping.
Name
Score
John
59
Bob
72
{{CTableStart|heading=A longer title needs to wrap for mobile portrait view, etc.. More text to test wrapping.|table-width=70%}}{|class=wikitable! Name !! Score|-| John || 59
|-| Bob || 72
|}{{CTableEnd}}
How to correctly mark up content displayed vertically
Latest comment: 8 months ago7 comments4 people in discussion
Of course, line breaks should not be used for purposes other than breaking up text semantically. The ubiquitous enlightened move is the use of HTML lists with no styling per templates like {{unbulleted list}}. However, this does not always seem like the best solution either, when it's harder to see components as items in a list, like within this table I've written. Is there a solid method to simply display blocks of content vertically without this carrying semantic information that harms accessibility and general correctness? Remsense诉00:10, 26 February 2024 (UTC)
Not really. Remember that people also often list things in a sentence like: I went to the grocery store to buy bread, milk, tuna and pasta. We don't go around marking that up as an unbulleted list either. Text has semantics as well. It's when we start removing the text, the commas, the 'or' and 'and's where things start to become a problem and artificial solutions need to be sought. —TheDJ (talk • contribs) 12:30, 3 March 2024 (UTC)
The example I'm thinking of is when people put line breaks to make words fit better into the header of a table column. Usually, the solution is to fix the width of the column, but this doesn't always work. Remsense诉12:34, 3 March 2024 (UTC)
No. Line breaks are semantically equivalent to a paragraph break, what is generally referred to as phrasing content in the HTML standard, as opposed to flow content.[6] It is indicating a "pause" or "break": pause for two seconds in your head if you encounter one while reading. From MDN:[7]
The <br> HTML element produces a line break in text (carriage-return). It is useful for writing a poem or an address, where the division of lines is significant.
The <br> element has a single, well-defined purpose — to create a line break in a block of text. As such, it has no dimensions or visual output of its own, and there is very little you can do to style it.
Creating separate paragraphs of text using <br> is not only bad practice, it is problematic for people who navigate with the aid of screen reading technology. Screen readers may announce the presence of the element, but not any content contained within <br>s. This can be a confusing and frustrating experience for the person using the screen reader.
Use <p> elements, and use CSS properties like margin to control their spacing.
I think in this case, there's at least two separate clauses separated with a colon. It's worst when it's done for only typesetting reasons. Remsense诉14:16, 3 March 2024 (UTC)
Guidelines around bulleted lists of non-sentences
Latest comment: 8 months ago5 comments4 people in discussion
Hi all, I was recently informed by Isaidnoway that a list article I wrote years ago, List of Mystery Dungeon video games, has some accessibility problems. Specifically, that the lack of periods at the end of each line in the "notes" sections resulted in screen readers reading the whole thing out as a run-on sentence. There doesn't seem to be any guidance on this in these guidelines that I could find; the examples in the list section all have periods as they are complete sentences, but the Bulleted vertical lists section uses two-word fragments and doesn't use periods. The only screen-reader software I have access to is Mac Voicover, which interjects a "bullet" at the start of each line, so I don't know what other software does. Essentially I'm asking two things: 1 is not having periods at the end of sentence fragments in a bulleted list an issue? And 2, if it is, can it be explicitly stated in the guidelines? As a delegate for Featured List Candidates I try to enforce ACCESS guidelines for lists, but I can't enforce something that's not explicitly written. --PresN22:38, 2 March 2024 (UTC)
@PresN and Isaidnoway: Both the windows screen readers I have access to, JAWS and NVDA, put list items like this on their own line ... and JAWS also adds a bullet; they both make it clear that each item is separate under normal conditions. The lack of punctuation might be a problem for some people but honestly it's a normal English formatting convention so if it's an issue, those people will have to get used to it. Screen readers mispronounce and misread things relatively often (even the word "misread" has two pronunciations ... like "misreed" or "misred") and proficient screen reader users get used to the idiosyncrasies of the system(s) they use. Graham87 (talk) 08:00, 3 March 2024 (UTC)
What Graham said. And I'd like to repeat a common point, that some people see all of this as some sort of black and white rulebook that has to be followed, which it is not. The guidelines have to be followed within reason, because that often will improve the situation, but they are not a directorate towards perfect accessibility, as such a thing doesn't exist. Correct mistakes where they apply, improve where possible, but don't take a weedwhacker at everything as a lot of nuance applies. Yes, having periods/punctuation at the end of sentences is probably better in many situations (especially when there is nothing like a list to distinguish the items instead), but that is not the same as "not having periods is forbidden" and it should not be something that should come up in a featured article review in my opinion. A lot of these kinds of things are intentionally not a rule, because it should not be arbitrarily enforced, it changes way too often to document or is pretty common outside the Wikipedia bubble of perfection. —TheDJ (talk • contribs) 12:23, 3 March 2024 (UTC)
Latest comment: 7 months ago3 comments2 people in discussion
I've been working on Chinese characters and related articles for a while, and one of my constant concerns is ensuring equal accessibility. Specifically, I've done a lot of work ensuring screen readers will function properly concerning the large amount of both tabular information and non-English information, but any insights or comments whatsoever would be appreciated.
It's this page. I can't think of anything more that can be done accessibility-wise (making non-Latin text accessible can be hard!), but thanks for your efforts. Graham87 (talk) 06:28, 1 April 2024 (UTC)
Latest comment: 7 months ago1 comment1 person in discussion
Some of you may remember that I've made it a point to add alt text and table semantics to articles for several years. Some of you may also know that I am under WP:0RR for edit-warring so I cannot engage in any reverting or otherwise undoing others' edits. I have had a recent article and template where I have added proper table semantics and someone else removed them and that someone is unwilling to re-add them. If anyone is motivated, see Template talk:2024 UFL standings and Talk:Michigan Panthers (2022). ―Justin (koavf)❤T☮C☺M☯23:09, 16 April 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)
Remsense诉 11:10, 1 April 2024 (UTC)
