Wikipedia talk:Manual of Style/Accessibility

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

Template:Xt, etc., and color

FYI

 – Pointer to relevant discussion elsewhere.

Some input relating to colorblindness and luminosity could be used here: Wikipedia talk:Manual of Style#Use of green and red in `xt` et al. templates.  — SMcCandlish ☏ ¢ 😼  03:04, 15 October 2023 (UTC)

Article in bad need of MOS:DLIST cleanup

FYI

 – Pointer to relevant discussion elsewhere.

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

https://en.wikipedia.org/w/index.php?title=List_of_state_highways_in_Tamil_Nadu&oldid=1183417868 Betty Logan (talk) 06:32, 5 November 2023 (UTC)

Wow. This slightly narrower diff link [1] is probably worth putting in a footnote as an example.  — SMcCandlish ☏ ¢ 😼  12:25, 5 November 2023 (UTC)

You really should have given us a Parental Advisory with that link, to give us a chance to put on our peril-sensitive sunglasses before viewing it. --𝕁𝕄𝔽 (talk) 20:01, 5 November 2023 (UTC)

I've just been watching "The Conscience of the King", "Balance of Terror" and "Shore Leave" back-to-back: there are plenty of colours there. --Redrose64 🌹 (talk) 20:19, 5 November 2023 (UTC)

At least the text wasn't blinking. Largoplazo (talk) 22:52, 5 November 2023 (UTC)

Put it in a frame, play a MIDI track, and take us back to the bad old days. Rjjⁱⁱⁱ (talk) 04:54, 15 November 2023 (UTC)

My eyes just crawled all the back into my brain. – The Grid (talk) 18:05, 15 November 2023 (UTC)

Making redundant table captions screen-reader-only

I know it's most important that table captions be present in the first place rather than necessarily visible to sighted readers, but the user User:Nkon21 has over the past several days been making all captions in the topic area they edit in of K-pop releases screen reader-only, despite this appearing to be a cosmetic change done solely for their own benefit/the benefit of sighted readers, when no other editor as far as I can see has had an issue with the captions being visible since they were introduced, let alone anybody expressing that their presence to sighted readers is a hindrance or an inconvenience. The user has repeatedly linked to Template:Screen reader-only, which states it "should only be used to hide text from sighted readers when that text substantially duplicates adjacent text that is visible" despite Wikipedia talk:Manual of Style/Accessibility/Archive 15#RfC on table captions concluding in 2020, around the same time this template was created, that captions should still be present (and therefore visible) even if considered redundant to sighted readers. For the record, this is primarily concerning making captions like "Chart performance for [song]" under headings like "Charts" screen reader-only, e.g. [2]. Thoughts on this? Ss112 00:58, 26 November 2023 (UTC)

I have no knowledge of precedent but the effect of adding {{sronly}} at Butter (song)#Weekly charts was to replace the somewhat silly dual headings such as Weekly charts / Weekly chart performance for "Butter" with just Weekly charts. I can see the point of Nkon21's edit. Johnuniq (talk) 01:48, 26 November 2023 (UTC)

@Johnuniq: I know why the edits were made, but adding visible captions to all tables has been done for years and nobody has raised a real concern in the years since that this repetition is somehow inconveniencing sighted readers and we should or now need to start hiding the captions with sr-only. The RfC at this very talk page in 2020 determined, even when editors in that discussion pointed out that the captions are repeating what's already known because of the headings, that they should always be included, with no great argument in favour of hiding them from sighted readers with sr-only. Ss112 02:57, 26 November 2023 (UTC)

Accessibility guidelines states that The caption element is the appropriate markup for such text and it ensures that the table identifier remains associated with the table, including visually (by default). In addition, using the caption element allows screen reading software to navigate directly to the caption for a table if one is present. 1) Captions are designed to distinguish table content from already existing text, but all of these captions are substantially the same as existing headers other than simply adding the subject of the article at the end of it, which adds basically no new value for readers. 2) Captions are a necessity in terms of accessibility for screen readers to navigate directly to the table. The RfC User:Ss112 linked had most of its support based on accessibility for screen reader software to function better, but using Template:Sronly makes that not a problem and there was no argument that was made against the use of it. So all in all, what are the point of captions? If they serve no purpose being visible than hiding them shouldn't be an issue. ɴᴋᴏɴ21 ❯❯❯ talk 03:46, 26 November 2023 (UTC)

@Nkon21: I'm not going to argue with you here about this, as I want the input of other editors more experienced in formatting matters, but this is coming out of nowhere. Nobody has raised a large concern about the apparent inconvenience of having repeated text in captions in the three years since they became a requirement; they've accepted them as a necessary part of having table formatting. (Not that MOS:DTT is exhaustive, but the how-to also makes no point to say readers can or should opt out of captions visible to sighted readers with the use of Template:Screen reader-only.) Some of the K-pop articles you hid captions from sighted readers on did not even have captions on some tables, which I had to insert, so it appears you don't necessarily care about ensuring that they're present for those who use screen readers, you would just prefer sighted readers and yourself not have to see the ones that are present, so I reverted those edits primarily because this appears to be about cosmetic appearance, not necessarily redundancy. As I pointed out, the 2020 RfC concluded that even if captions are repeating text that sighted readers know from the headings, they are still a necessary part of table formatting. I don't feel "but captions are repeating context from the headings" would have been raised as a concern and then "but they're still necessary" would have been concluded if we should just hide the captions from sighted readers. Ss112 05:36, 26 November 2023 (UTC)

Perhaps this discussion should focus on exactly what "Data tables should always include a caption" means at Wikipedia:Manual of Style/Accessibility#Data tables. The RfC linked in the OP clearly intended the caption to be a requirement for screen readers and I don't know what discussions have occurred regarding visible captions. At any rate, Nkon21 should definitely not continue making changes until this is resolved. Johnuniq (talk) 05:42, 26 November 2023 (UTC)

The "trend" was started by Flabshoe1 to Blackpink's related articles. In which Nkon21 followed suit with bulk editing. I personally agreed with Ss112 POV. In addition, I don't see why we're going against MOS guidelines and RfC, did IAR suddenly applies? — Paper9oll (🔔 • 📝) 06:54, 26 November 2023 (UTC)

But there is no MoS provision being violated, and this is not contrary to the RfC results in any way.  — SMcCandlish ☏ ¢ 😼  09:27, 26 November 2023 (UTC)

While the MOS doesn't explicitly stated no usage of sronly, the examples provided and wording implied the caption should always exists for accessibility sake. Of course, we haven't even go into table created via templates yet, does the caption that duplicates the heading needs to be hidden also? Then, that would require modification to the templates itself. I don't see why we should be introducing inconsistency as stated repeatedly by Ss112 above or below. If it ain't broke, don't fix it. — Paper9oll (🔔 • 📝) 09:38, 26 November 2023 (UTC)

But redundant visible table headers and captions are "broke". Next, the captions do still exist for accessibility's sake. Are you sure you even understand the nature of this discussion and what {{sronly}} does? I'm getting the impression you think that the captions are being hidden from everyone including the screen-reader users they are there for, but that is not what is happening. Finally, the fact that some templates would have to be adjusted to account for something (if we actually wanted to make an MoS rule for {{sronly}} hiding of redundant captions, which I opposed in the first place, while also opposing one editor here's apparent belief that this use of {{sronly}} should for some reason be prohibited) is never a reason to not do something, or half of MoS would just be deleted. In actual reality, of course, the template tail does not wag the encyclopedic dog. Templates are tools of convenience for us, and must be bent to our needs; they are not the (or even "a") purpose of the project.  — SMcCandlish ☏ ¢ 😼  00:03, 27 November 2023 (UTC)

Broke where? MOS doesn't states nor implied that unless I'm blind myself. Neither, did I stated it was removed completely because of {{sronly}} usage. The only thing broken I see is introducing inconsistency, and yes, the template should and must also be updated to match if there is where the consensus is heading to ensure consistency in album/song articles. Regardless, my stand remains the same, and this would be my last reply here to you. — Paper9oll (🔔 • 📝) 00:35, 27 November 2023 (UTC)

Broken everywhere we have redundant table captions, for everyone not using a screen reader, by the very fact of being redundant. We do not need a "rule" to write non-redundantly; we just write non-redundant because it is better writing. WP:COMMONSENSE exists for a reason. There is no principle anywhere on Wikipedia that article content has to be consistent from page to page (and lots of guideline material to the contrary, e.g. permitting different date formats, different English-language dialects, different citation styles, presence or absence of infoboxes, different content sections even in the same article type like scientist biographies or whatever to best suit the exact article subject, and so on). It would not be bad thing for articles to consistently use {{sronly}} to hide, for non-screen-readers, table captions that are redundant, but there is no evidence that the community wants a rule to require such a consistency. Meanwhile it would be a bad thing to undo hiding of completely redundant table captions, for non-screen-readers, on the basis of a completely imaginary idea that articles must be completely consistent from one to another. My mind is kind of blown that I've had to spell this out more than once for more than one user here.  — SMcCandlish ☏ ¢ 😼  01:00, 27 November 2023 (UTC)

I have to lean toward the interpretation of Johnuniq and Nkon21, for captions of this sort. They are entirely duplicative of the table headers, and serve no function for fully-sighted users, but are arguably necessary as navigation points for users of screen readers, so keeping them but putting them in {{sronly}} is a good idea. I can imagine some cases where table captions are more informative, for both sets of readers, and in such cases should not be hidden. The fact that Nkon21 thought to use {{sronly}} on the redundant ones before anyone else did doesn't make it somehow an error or a problem. "Nobody has raised a large concern" = no one really cares all that much either way. No harm is being done by these specific caption-hidings, and the result is demonstrably better (in being much less redundant) for fully-sighted readers at no cost to sight-impaired readers, so overal what Nkon21 has been doing (at least in these specific cases) is a net benefit and not just "cosmetic".  — SMcCandlish ☏ ¢ 😼  06:48, 26 November 2023 (UTC); revised 00:03, 27 November 2023 (UTC)

Long digressive argument

@SMcCandlish: If that is to become the consensus that forms, it should be noted somewhere, perhaps on MOS:DTT, that if the table caption duplicates the section headings they can be hidden, because it's not stated anywhere and for posterity (and to cite) it should be. But I can still see what is considered "informative" and requires a caption being visible to both sets of readers being a significant point of contention. I must say, not that articles will be ever uniform in most regards, but it's of no benefit to anybody for it to be inconsistently applied—some tables on the articles having sr-only, some tables not having captions at all, and editors (like Nkon21) only caring to hide and even actively reverting over having captions in their topic area of music hidden, whereas every other (or most other) music articles have captions visible to fully-sighted readers in tables. At least in that regard I'd like to have uniformity as to whether they "should" all be hidden from fully-sighted readers or not, because for the last three years I've been trying to make them consistent. Ss112 07:18, 26 November 2023 (UTC) WP:NOT#BUREAUCRACY and MOS:BLOAT and WP:CREEP. Not everything that editors do that isn't against consensus has to be written down as a rule (or a codified exception to one) to follow. MoS and other guidelines would be much, much longer otherwise, and all we would do is litigate constantly about what to add to them and what they should say. Every line-item added to a guideline or policy is a potential morass of conflict with some other rule somewhere; WP:Policy writing is hard. Basically, "that which is not forbidden is permissible" (cf. WP:EDITING policy), and we have no reason to write down everything imaginable that is permissible. Something should be added to a guideline only with consensus, and only when it needs to be added to forestall longterm, repetitive fights between editors. So, far only one editor that we know of has ever raised a concern about this (and primarily on rule-based and hypothetical-leaning grounds rather than on arguments about actual utility to readers); that's really not justification for a new rule-making. The outcome of this discussion alone (whatever that outcome will be) should be sufficient as something to refer to. As for "it's of no benefit to anybody for it to be inconsistently applied—some tables on the articles having sr-only", that's demonstrably not correct, because reducing pointless redundancy even in a single article is a net benefit at that article. The very fact that "articles will be ever uniform in most regards" (which is correct) means we have no reason to be concerned about lack of someone going around to "consistentize" thousands or tens of thousands (who knows?) of articles in short order and applying the same markup change. Doing it robotically could even raise WP:MEATBOT concerns, as well as hide captions that are actually informative for both sets of readers, which you seem to have a concern about in the first place.  — SMcCandlish ☏ ¢ 😼  07:58, 26 November 2023 (UTC) @SMcCandlish: I was trying to echo what @Johnuniq: said above, about what exactly Data tables should always include a caption means. I meant it could be specified in a few words. I never get involved in trying to change guidelines or policies, so my thinking this one exception is worth additional specification on a how-to guide (not the guideline itself) is hardly worth bringing up an argument that if this were always the case the Manual of Style would be much longer about. It's a suggestion. As for the WP:MEATBOT comment, no disrespect but I lost the train of thought you were on—I interpreted that as you saying that my "consistentiz[ing]" the music articles that have tables on them by making them have visible captions is me acting like a "meatbot", and as that applies to editors making a lot of errors in fast editing I hardly see how that would make sense in relation to me if that's the case. As for your "rather than on arguments about actual utility to readers", I know you didn't explicitly say so but I don't think it's at all a negative for me to try to seek additional input on somebody trying to enact what I think is still a cosmetic workaround because they've decided captions are now redundant and they don't want to see them (and I say cosmetic because the caption is still in the HTML, just not visible in the output). I thought maybe somebody might argue that captions are of use to fully sighted readers in a way I had not considered or some such. Ss112 08:53, 26 November 2023 (UTC) Whether a caption "should always be included", for the benefit of screen readers, is irrelevant to whether it is permissible to hide redundant ones from non-screen-reader users. And "in a few words" isn't relevant either; due to their nature, table captions should almost always be just a few words. On MEATBOT: To clarify, I was responding further to your argument that there was "no benefit" to hiding redundant captions inconsistently across articles, which necessarily implies that if there is no consensus against what Nkon21 is doing, that it should be done everywhere, necessitating that someone(s) actually do it. That doesn't mean it is necessarily you doing it. Someone doing this robotically across thousands of articles, without making more substantive edits at the same time, and perhaps doing it inappropriately in some cases (of non-redundant captions) would probably trigger MEATBOT objections. I.e., it is something to do with thought and care, on an as-needed basis, and hopefully in a way that doesn't trigger people's watchlists over and over again for a comparatively trivial kind of change that no one is clamoring for. This is about on the same level as tweaking a citation's parameters in ways that just make it more consistent with the rest of the citations in the page (per WP:CITEVAR) but without actually improving the citation in any way for readers. Editors don't like such trivial tweaks being done (thus MEATBOT policy) unless they are part of a more substantive edit. Your understanding of what "cosmetic" means in this context does not agree with Wikipedia's definition (for which, see WP:COSMETICBOT): the very fact that it makes a meaningful difference in the rendered output makes it non-cosmetic, axiomatically. "I thought maybe somebody might argue that captions are of use to fully sighted readers in a way I had not considered or some such." But they're not, so what is the purpose of all this circular argumentation against Nkon21's (and Flabshoe1's) demonstrably useful table tweaking and your near insistence that we need to address it one way or another in a guideline? We just don't. It's not harmful and it is helpful (at least in the cases diffed so far), but really no one cares much either way, so there is no rationale to make a rule to enforce it site-wide, much less a rule against doing it. This has all the earmarks of a tempest in a teacup.  — SMcCandlish ☏ ¢ 😼  09:27, 26 November 2023 (UTC) Good stuff, but you're replying on automatic. Please just consider how odd it is that the guideline says "Data tables should always include a caption" but someone goes around making captions invisible which effectively removes them. Something is needed to clarify the situation even if it's a discussion somewhere focused on that one issue so it can be linked to. Johnuniq (talk) 09:46, 26 November 2023 (UTC) "making captions invisible which effectively removes them" isn't accurate. They exist almost entirely for scree-reader users (some uses of them that would be of benefit to fully-sighted readers may exist here and there, but they are rare), and the changes in question have no effect on those users, nor has anyone proposed (or, that we know of, engaged in) hiding the ones that are not just redundant reiteration of the table headers. And this already is "a discussion somewhere focused on that one issue so it can be linked to" (ultimately in a talk archive page), though this could also be re-done as a more clearly stated RfC, I suppose. If both you and Ss112 are convinced that the MoS section about this should explicitly mention using {{sronly}} around table captions that are redundant, then I'll stop objecting to the idea, despite being a strong resister of more MOS:BLOAT. But so far, Ss112 appears actually opposed to use of that template for this purpose at all, and rather singlemindedly bent on pillorying Nkon21 (maybe also Flabshoe1 now) for making this novel use of it, as if WP:EDITING policy didn't exist. MoS talk pages are not a disciplinary venue, there is no actual disciplinary issue here in the first place, and MoS pages (and other guidelines) do not exist to enshrine random editors' passing and overreactive ideas about what should or should not be permissible – only to record consensus-accepted best practices and to have, when necessary, often arbitrary rules that simply forestall recurrent editwarring. The only "drama" about this at all has been manufactured out of thin air by Ss112.  — SMcCandlish ☏ ¢ 😼  00:03, 27 November 2023 (UTC) @SMcCandlish: Okay, this is going nowhere and now resulting in misunderstandings. My "in a few words" comment was meant to mean if we were to specify somewhere "what exactly Data tables should always include a caption means" (as Johnuniq has just said), not the wording of table captions. In addition to that, I disagree with your "tempest in a teacup" comment, general argument, and unnecessary refactoring of this very section's heading and inserting your own POV ("redundant") while implying I'm the one who was not being neutral by apparently being "alarmist" and "misleading" with my original heading, when this is not a formal RfC nor did I intend it to be a pseudo-one so there was no imperative for me to be exactly neutral, and I very much consider changing 40+ music articles mass-scale in that area so what exactly was "misleading" let alone "alarmist" I'm not sure. I'm not replying to you any longer here as it's resulting in unfavourable characterisations of why I came here, what I've written and I'd prefer you not do that and that not happen at all. I would like a variety of editors commenting and my replies seem to be just prompting more long passages from you that I feel are going to discourage anybody else from offering their input. Thanks. Ss112 10:00, 26 November 2023 (UTC) I've addressed most of this in user-talk because it's not actually pertinent to this discussion, which should remain focused on the actual subject of using {{sronly}} on redundant table captions. The short version: The fact that the ones at issue above are redundant is not a "POV", but a bare fact; and your original heading was alarmist and misleading in four different ways, as detailed at your user page. That said, this round-in-circles argumentation is in fact making for a long blob of text here that may be discouraging to other participants, so I'll be happy to collapse box all this digression.  — SMcCandlish ☏ ¢ 😼  00:03, 27 November 2023 (UTC)

I agree that having much less redundancy is a net-benefit for articles as visible dual captions offer zero net-benefit for either sighted or screen readers in any substantial way. If they offer no use, then I don't see a strong argument here against the use of Sr-only that's not WP:OTHERCONTENT. ɴᴋᴏɴ21 ❯❯❯ talk 20:31, 26 November 2023 (UTC)

Resolved dispute about thread heading

A point of order: I changed the original confusing heading to "Making redundant table captions screen-reader-only", and this has since been altered again to "Making table captions screen-reader-only" which is grossly misleading. There is no evidence of any kind that anyone has been, or has even proposed, using {{sronly}} to hide all table captions from non-screen-readers, only those that redundantly reiterate the content of the table headers. That is the only thing that has been under discussion here, and the only thing demonstrated in any diffs. The fact that someone is editwarring to keep the title of this discussion alarmist and misleading is a bad sign, and will likely trainwreck the discussion. Someone should probably open a more formal RfC on this matter (which I think is what Johnuniq wants to see happen also), perhaps at WP:VPPRO since ultimately this could affect a large number of articles in any category, not just the music one that this discussion opened with.  — SMcCandlish ☏ ¢ 😼  00:53, 27 November 2023 (UTC) @SMcCandlish: It is not "grossly misleading" at all. Nkon21 hid all the table captions on articles that I could see. "Redundant" is a loaded word and I firmly believe it is still your POV, so I removed it from the heading. It is in no way an "edit war" to remove "redundant" from a section heading that you refactored in the first place—I didn't revert you or anybody here, I refactored your refactor, that's it. First you accuse me of being alarmist and misleading, now I'm alarmist, misleading and edit warring when I didn't perform a single revert anywhere here? I invite your input directly and now all you're doing is throwing out bad-faith accusations at me and claim what I'm doing will trainwreck the discussion? I think you and your paragraphs have already derailed this discussion and discouraged other people from replying and it's already a trainwreck. This is ridiculous. Please stop accusing me of things I did not do. Now, I am fine with the heading as it stands. It doesn't need every specification in it. Editors can read from my first comment what I am specifically talking about. This could apply to any number of areas in making table captions sr-only. Just because it started in music where it repeats what is in section headers does not mean it couldn't affect other topic areas and where they have table captions more broadly. Ss112 01:49, 27 November 2023 (UTC) Already covered in detail at your talk page [3] and mine. "Redundant" certainly is not a "loaded word", it's a descriptive one with an objective definition. Check any dictionary you like. Typical definitions are "characterized by unnecessary words or repetition", "superfluous", "exceeding what is needed or useful", all of which unmistakably, as a matter of plain fact not opinion, apply to literally repeating in a table caption the same words that are in the table headers, which was the only sort of case under discussion, despite your tendentious attempts to raise false editorial alarm by implying the discussion was about hiding every single table header. When someone clearly demonstrates, in discussions on three different pages, why something is misleading and objects to it, reinstating the misleading language and just asserting "it is not" misleading, certainly is editwarring.  — SMcCandlish ☏ ¢ 😼  03:54, 27 November 2023 (UTC) I am done replying to you beyond this point because you have taken this in some kind of serious misconduct direction. Please stop posting on my talk page as I have requested here and here; nothing here is as serious as you're trying to make it out to be. I did not edit war and I do not think I am being misleading by removing your claim of table captions below headers being "redundant". That's not an edit war because no reverts took place—I didn't "reinstate" anything. I made one adjustment to a heading. For the record re: your comments on my talk page, Johnuniq "suggesting [...] that "should always include a caption" could ambiguously be interpreted to mean that the caption must always be visible to everyone [...] and that we should have that discussion" is exactly what I meant as well and literally what I tried to get at in this discussion before it got sidetracked. We should be having that discussion. I also never insinuated or stated I wanted the use of sr-only to be forbidden. I don't want it to be as I still see it as useful in other places. Thank you. Ss112 04:35, 27 November 2023 (UTC) This seems to have resolved itself in user-talk, fortunately. :-)  — SMcCandlish ☏ ¢ 😼  08:13, 27 November 2023 (UTC)

It's nearing 2 weeks with no new comments here and I'm wondering how we are going to move forward. Is there a consensus? Or should an RfC be opened? ɴᴋᴏɴ21 ❯❯❯ talk 22:59, 8 December 2023 (UTC)

I don't believe there's a consensus here. I support a (neutrally worded) RfC being started, but also, I don't think there's any rush for there to be a consensus if one is to form here. As SMcCandlish has pointed out, it's not a very watched talk page. Ss112 03:22, 9 December 2023 (UTC)

Well, a) there is no rule against using {{sronly}} to hide redundant table captions; b) doing it is objectively an improvement for fully-sighted readers and does no harm for screen-reader users; c) one editor came here with a wild hare to ban this practice; d) nothing like a consensus emerged to do so; e) the status quo thus has not changed: it is entirely permissible to do it; f) various noise was made along "what if people do it to non-redundant captions?" lines, but there is no evidence of this happening (if it does happen, reverting would be covered by WP:COMMONSENSE and the template's own documentation: it is not for hiding content that is not pertinent only to users of screen readers).

The only thing we might want to have an RfC about is whether MoS should recommend {{sronly}}-hiding of redundant table captions, but WP:CREEP and MOS:BLOAT would suggest we should not go there, since this is not something that editors are frequently in conflict about, so no reason to add a rule about it. And it is not a discussion for this page in particular, but for WT:MOSTABLES, since this has no accessibility implications at all.  — SMcCandlish ☏ ¢ 😼  06:24, 9 December 2023 (UTC)

@Johnuniq Do you have any thoughts? ɴᴋᴏɴ21 ❯❯❯ talk 09:29, 10 December 2023 (UTC)

In my reply to the OP I tried to clarify the issue to make it easier for others joining the discussion. Apart from that I don't have an opinion except for two points: (1) people should not do mass edits against objection without gaining a clear positive consensus; (2) it's crazy for a guideline to say that a caption should always be included while people go around making them invisible. If there is still a dispute, start an RfC after drafting a comprehensible question. Johnuniq (talk) 09:44, 10 December 2023 (UTC)

it's crazy for a guideline to say that a caption should always be included while people go around making them invisible I'm not sure what's crazy to be honest; the 2020 RfC never suggested that table captions are required to be visible, just that captions should exist. Sr-only does not remove captions and hiding redundant ones do not go against any already established consensus. People who has opposed them so far have solely cited inconsistency concerns, which in my opinion is trivial as the benefits outweigh it. ɴᴋᴏɴ21 ❯❯❯ talk 09:53, 10 December 2023 (UTC)

What if I went around making things I didn't like invisible? And people asked me to stop. So I replied "the text is still there; who says it should be visible?". You don't think that would be somewhat crazy? Johnuniq (talk) 02:08, 12 December 2023 (UTC)

Not a valid comparison, on at least two grounds: Hiding redundant captions from the fully-sighted audience is a practicality matter not an WP:IDONTLIKEIT one; and making content invisible to/hidden from everyone is different from making screen-reader content available to screen readers but not pushed on everyone. In order for your premise to be valid, the {{sronly}} template would never have existed (or at very least would be WP:TFDed right this second and would be deleted with prejudice, but of course that's not going to happen). To put it another way, by your reasoning (at least taken to its logical conclusion), we would also have to find a way to force the display of all alt text for images so that non-screen readers could see it.  — SMcCandlish ☏ ¢ 😼  21:28, 12 December 2023 (UTC)

@SMcCandlish: I am not intending to start another argument, but please do not put words into my mouth. Nowhere in my original reply or in this thread have I said we should "ban" the use of sr-only templates. I believe I even said somewhere on your talk page I didn't support "banning" the practice—I'm quite sure I said somewhere it has a use. Regardless of our long disagreements over other matters on your talk page, including this very section's heading, my intention here was to start a discussion on whether what Nkon21 was doing should be done or not, not to outright "ban" the use of the sr-only template. Unfortunately this hasn't gotten the amount of feedback I would have liked and has gotten so sidetracked I no longer particularly want to engage here so am trying to keep my replies as brief as possible. If I wanted sr-only to no longer exist, I would have proposed the deletion of the template, not come here or sought others' input. I fully agree with what Johnuniq said dated 09:44, 10 December 2023. Johnuniq has gotten to the point and made my intention clearer here than I have. Thus I no longer want to be involved in this, but I would really prefer editors not misrepresent or misstate my purpose because of what they believe when I never explicitly said such things. Thanks. Ss112 13:42, 11 December 2023 (UTC)

I'll strike mine too, then. No one needs to wade through this. The entire thrust of your participation in this discussion has been prohibiting Nkon21 or anyone else from doing this, which is clearly arguing for a ban on it even if you didn't use the word "ban". (That said, you have also veered at times into statements that seem to indicate you're actually taking a devil's-advocate position and making these arguments simply because you think there is some kind of guideline inclarity or conflict you can force to be resolved this way, which is a simultaneous WP:POINT, WP:LAWYER and WP:BUREAUCRACY behavior problem). This entire thread never should have existed, because Nkon21 and Flabshoe1 were not breaking any rules or doing anything unhelpful, and there is no evidence of any kind of conflict or other problem caused by their edits, so you have generated a mountain out of molehill for no reason at all. It might have been reasonable to ask a neutral and claim question about whether these edits had any accessibility or other implications, but instead you came in here with accusations and ranting against another editor, claiming what amounts to wrongdoing by them, with no evidence of any kind. You have consistently failed to understand what "cosmetic change" means, and repeatedly completely confused the notion that the table caption should exist for the benefit of screen-reader users, with the unrelated notion that this caption must be visibly presented to everyone even when it is redundant with the table headers. This (and the associated user-talk circular argumentation) has been a total waste of time and a strain on editorial good will. Not to mention all the editwarring to suppress particular wording you didn't understand, and other shenanigans.  — SMcCandlish ☏ ¢ 😼  14:09, 11 December 2023 (UTC); struck 15:30, 11 December 2023 (UTC)

"If there is still a dispute, start an RfC after drafting a comprehensible question" is correct. There seem to be two editors who have some concern about this, and I don't think that's sufficient grounds for an RfC; RfCs consume community time, attention, and energy, and there would have to be a strong showing that hiding redundant captions violated some kind of principle or goal, but there is zero evidence of that anywhere, so we already know how such an RfC would turn out. But go ahead and do one anyway, if you insist.  — SMcCandlish ☏ ¢ 😼  14:09, 11 December 2023 (UTC)

Side question re aria-description

In our modern times, is using the aria-description attribute of a <table> tag instead of a caption a suitable way to introduce the table to screenreader users without producing disruptive redundancies for visual users? Do modern screenreaders pick up that attribute when a user calls for a listing of the tables present on a page? If so, is that technique worthy of consideration? Largoplazo (talk) 01:12, 27 November 2023 (UTC)

@Largoplazo: I don't know ... got an example? On a quick Google that's not exactly how it works ... Graham87 (talk) 05:42, 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)

Proposal to discourage vertically oriented ("sideways") column headers in tables

I have initiated a discussion at Wikipedia talk:Manual of Style/Tables#Proposal to discourage vertically oriented ("sideways") column headers, to may interest contributors to this article. 𝕁𝕄𝔽 (talk) 17:13, 6 December 2023 (UTC)

Paragraph breaks in a comment

Note: This discussion moved from user talk page to get more input.

Hello Timeshifter,

It seems that we have gotten into a few disagreements lately. I hope you know that I bear no ill will towards you; I firmly believe you are doing what you believe to be in the best interests of Wikipedia. I hope that our editorial disagreements do not stop us from being friendly towards one another.

I wanted to drop you a note about making paragraph breaks in a comment. Per MOS:PARABR, using multiple colons to create paragraph breaks is not accessible. We use list markup for comments, and generally one entry in the list should correspond to one comment. When you use colons like this:

:Here is one paragraph.
:Here is another paragraph.
:Here is a final paragraph. [SIGNATURE GOES HERE]

screen readers cannot distinguish it from:

:Here is one paragraph. [UNSIGNED COMMENT]
:Here is another paragraph. [UNSIGNED COMMENT 2]
:Here is a final paragraph. [SIGNATURE GOES HERE]

Instead, it is best to use {{pb}}, like this:

:Here is a paragraph. {{pb}} Here is another paragraph. {{pb}} Here is a final paragraph. [SIGNATURE GOES HERE]

{{pb}} works like <br>, but has different semantics. <br> is used to create a visual line break; {{pb}} separates two different paragraphs. Best, HouseBlaster^talk 03:41, 13 December 2023 (UTC)

HouseBlaster. I don't think this is true for talk pages.

It has been my understanding that the main thing is to avoid blank lines in indented comments.

--Timeshifter (talk) 03:56, 13 December 2023 (UTC)

It's not such a big deal for talk pages and lists without bullets, know. Screen readers read each list item (or pseudo-item in this case) on its own line, so the separation is still there. The only difference between the two forms of markup above is that in the one with explicit paragraph breaks, each new paragraph is actually read as a blank line. Graham87 (talk) 16:23, 13 December 2023 (UTC)

Graham87. So colons are fine? I have never seen {{pb}} used on a talk page. --Timeshifter (talk) 16:38, 13 December 2023 (UTC)

@Timeshifter: Yep, they're not worth worrying about. Graham87 (talk) 16:46, 13 December 2023 (UTC)

Thanks. HouseBlaster, Graham87 is a blind admin who uses a screen reader. --Timeshifter (talk) 07:06, 14 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.

--Timeshifter (talk) 11:02, 14 December 2023 (UTC)

Yep, that's correct. Graham87 (talk) 15:04, 14 December 2023 (UTC)

TheDJ and Graham87. If a comment includes a table:

Caption text

Header text	Header text	Header text
Example	Example	Example
Example	Example	Example
Example	Example	Example

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 (talk) 01:11, 24 December 2023 (UTC)

@Timeshifter: Yeah colons are fine in situations like this. Graham87 (talk) 01:31, 24 December 2023 (UTC)

@Timeshifter: I can add to that. If a table is indented with colons (as in your first example), the list is continuous; but if an unindented table appears between two indented lines (as in your second example), there are now two distinct lists, and that is essentially a WP:LISTGAP problem. --Redrose64 🌹 (talk) 20:40, 24 December 2023 (UTC)

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 />&nbsp;<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)

Links within section headings

At WT:MOS there is a discussion regarding the technical reasons not to put links into section headings. If users here have insight on accessibility or technical reasons for the practice, please join us: Wikipedia talk:Manual of Style#Header links: technical reasons. — HTGS (talk) 04:13, 13 December 2023 (UTC)

single-item lists

The template {{infobox cocktail}} automatically forces a bulleted list for its main-alcohol parameters; bulleted lists in infoboxes aren't unheard-of, though rare. However, that template forces a bullet even for single entrants, making the oxymoronic single-item list. Given there is no actual list created, should that template be invoking list markup for single variables? For example, in the infobox's implementation at mojito, there's a bulleted list with one item (rum). Given how the bulleted-list markup interacts with other variables like scrapers, screen readers, and more, are there any technical or accessibility (or grammatical or stylistic) problems caused by a 'list' that then only has one entrant? — Fourthords | =Λ= | 15:27, 30 December 2023 (UTC)

As a screen reader user, not really ... it's slightly annoying but not unusual at all and certainly not the end of the world. Graham87 (talk) 02:25, 31 December 2023 (UTC)

Advice on impact of image links on screen readers

Hi. Over at Wikimedia Commons, there is currently a discussion about whether removing the links from images to the image details page will help users of screen readers. It would be useful if any users of screen reader software can provide their thoughts on the discussion. See c:COM:VP#Usage of files with link to file removed. From Hill To Shore (talk) 17:29, 3 January 2024 (UTC)

WP:NCTV discussion on titles of TV season episode list articles (punctuated or not)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Naming conventions (television)#Follow-up RfC on TV season article titles. This is round two of a consensus determination on how to format the names of such articles, and an accessibility concern about one of the options has belatedly come up (namely, using no punctuation of any kind between series title and season designator, just relying solely on italics to clarify).  — SMcCandlish ☏ ¢ 😼  05:34, 8 January 2024 (UTC)

Nested tables. Are they ever accessible?

See:

• Help:Collapsing - Its examples are nested tables.
• Help:Table#Nested tables - Its example consists of complicated nested tables. Is it accessible?

--Timeshifter (talk) 14:28, 13 January 2024 (UTC)

YES!...

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.

Player	Matches	Goals
Guðmundur Hrafnkelsson	407	0
Guðjón Valur Sigurðsson	364	1,875

Total number of goals scored in official matches only.

Player	Goals	Matches	Average
Guðjón Valur Sigurðsson	1,875	364	5.15
Ólafur Stefánsson	1,570	330	4.76

Narrow your browser screen to see the tables wrap (one drop below the other). Works in mobile view too. --Timeshifter (talk) 17:14, 13 January 2024 (UTC)

I don't want to deal with this. Graham87 (talk) 08:08, 14 January 2024 (UTC)

Role=math

The following problem was reported regarding {{Fraction}} back in 2022 at Template talk:Fraction/Archive 2#Fractions are not readable with screen readers or virtual assistants and Template talk:Convert/Archive 3#conversions using the frac parameter are not accessible with screen readers [[by KaraLG84, who uses a screen reader, and wrote: "The resulting output when frac is used either reads as "math", the formula or nothing at all depending on the screen reader used, not the actual text displayed. The same is true when a virtual assistant such as Siri tries to read frac output visually." It seems to affect most screen readers except the one I personally use, JAWS, which is why I never reported it. I just got an alert she sent a few days ago off-wiki about the TFA for 11 January, which used this template. I played around with it in User:Graham87/sandbox26 and User:Graham87/sandbox27 and discovered that the actual problem is role=math ... it seems some screen readers *expect* MathML within that role per this from MDN Web Docs, which we don't provide. Since this change only impacts accessibility, I'm going to boldly make it to affected pages, like {{Fraction}}, {{Sfrac}}, and Module:convert. Graham87 (talk) 08:09, 14 January 2024 (UTC)

The only problem with the templates now is that when they're run together with just spaces in between them like at this documentation subpage, both the popular Windows screen readers JAWS and NVDA read them out without the spaces, probably due to the CSS magic (e.g. "1/21/3" instead of "1/2 1/3". I'm going to put commas in between to stop that. Graham87 (talk) 08:42, 14 January 2024 (UTC)

Visually, the result is pretty crapful. One wonders whether some of the alternative whitespace characters might be usable instead. Some potential candidates might be: A) medium mathematical space,   (with a capital first M and capital S) or   and B) punctuation space   or   and C) four-per-em space,   or   and D) three-per-em space,   or  . Those would have the closest appearance to a regular space (without also being non-breaking).  — SMcCandlish ☏ ¢ 😼  09:03, 14 January 2024 (UTC)

@SMcCandlish: OK, I've self-reverted. JAWS likes all but the first option but NVDA doesn't 100% like any of them (it reads them as unknown characters)). I'll just put up with it for now. Graham87 (talk) 09:22, 14 January 2024 (UTC)

Well, it's not that bad; if the commas are needed, they are. Maybe there are invisble commas. :-)  — SMcCandlish ☏ ¢ 😼  11:57, 14 January 2024 (UTC)

I've come up with another idea ... I used {{sronly}} to make them only visible to screen readers (hopefully without messing anything else up in the process!). We can find all the unusual characters we like, but as the guideline says: "Screen readers have widely varying support for characters outside Latin-1 and Windows-1252 and it is not safe to assume how any given character in these ranges will be pronounced." Graham87 (talk) 14:36, 14 January 2024 (UTC)

For posterity, I'm recording some links. I never fully understood role="math" although I received an explanation at Template talk:Convert/Archive 2#Module version 25 (see May 2021 for release) (search for "For my curiosity"). Apparently it was added to {{sfrac}} on 19 September 2019 by Crissov (diff) and was copied to {{frac}} and Module:Convert later. Johnuniq (talk) 09:09, 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)

Thanks, that's pretty conclusive. Johnuniq (talk) 02:15, 15 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. — Christoph Päper 13:50, 15 January 2024 (UTC)

It is clear that essentially anything that represents math can carry the Math role. Yet another example of browsers having incomplete interpretations and the standards not being clear enough to avoid these problems (A common issue with ARIA honestly). I'm personally not very favourable of working around issues like this as it doesn't motivate the companies in question to actually FIX these problems. But as the track record of said companies on fixing accessibility problems is not especially stellar, it is a bit of a balance. —TheDJ (talk • contribs) 14:18, 15 January 2024 (UTC)

Query about anchor behavior

@Graham87: Something I've been wondering for some time is whether it makes a difference in screen readers whether an HTML anchor is at the beginning of a line or the end of one as long as its on the same line. I mean anchors such as created by <span class="anchor" id="Foo"></span>, or by use of the {{anchor}} or {{vanchor}} templates. Visually what happens is the browser jumps to the line and (at least in some browsers) the line gets highlighted. This kinda-sorta suggests that the screen reader would read from that line onward, but for all I know it might read from the span point onward, or it might vary radically from screen reader to screen reader. I ask this mostly with regard to headings in which a former name of the section is preserved as an anchor for incoming-link purposes. These spans mostly seem to be added to the end of the heading (because putting them at the front of the heading makes it hard to tell what the section is when in wikicode viewing mode).  — SMcCandlish ☏ ¢ 😼  08:47, 14 January 2024 (UTC)

I don't think so, but screen readers behave oddly with anchors at the best of times, so it'd be hard to test properly. I wouldn't change that practice just for that reason, anyway. Graham87 (talk) 09:03, 14 January 2024 (UTC)

Okey-dokey. Thanks for the feedback.  — SMcCandlish ☏ ¢ 😼  11:59, 14 January 2024 (UTC)

Are these nested tables accessible?

My last thread was way too complex of a question. With no simple answers. The following is a lot simpler. The nested tables example below is in use on a help page. It does not wrap (a problem in cell phones, especially in portrait view). Is it accessible? It is followed by the divs method which wraps (narrow your browser screen), and is already acknowledged as accessible.

Pinging Steelpillow since he seems to know something about this from another discussion. Apparently, some nested tables, when formatted correctly, are accessible. See:

• How can you make a table with nested tables WCAG AA compliant.

Nested tables:

Code entered	Output produced
{|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.

Name	Score
John	59
Bob	72

--Timeshifter (talk) 15:05, 14 January 2024 (UTC)

Both examples are fine by me. Graham87 (talk) 15:11, 14 January 2024 (UTC)

Works just fine on my screen reader. Moxy- 15:15, 14 January 2024 (UTC)

steelpillow here. Both the table and css versions appear sensible to me, though I do not have a reader handy. Unfortunately, "accessible" and "conformant to WCAG" are not necessarily the same thing. In practice, "accessible" means that a sensible range of screen readers work on your page. But some screen readers are more sensible than others, as are ways of using tables and/or divs. For example the html attribute:"value" role="presentation" can desensitise the screen reader to some issues - but it can create other issues of its own. Different readers may respond to it differently. What really kills accessibility is when the code breaks normal flow. Be it nested tables or cunningly repositioned divs, if the ordered flow of content in the page code does not match the intended ordering presented to the user, then all hell will break loose. This can happen with, say, a div floated to the right so it will be read afterwards, but coded into the page first so that the lefthand content, placed after it in the code, flows down alongside it and visually presents first. Similarly, you can nest tables badly so that the visual flow keeps jumping between tables instead of just dealing with the second table as a unit. IMHO the official guidelines are just too deep down the techno rabbit-hole. The mantra should be: NEVER BREAK NORMAL FLOW. And neither of these examples does. At least, that is my experience, but I know little of the current official state of play. — Cheers, Steelpillow (Talk) 17:11, 14 January 2024 (UTC)

Thanks steelpillow. I think I am beginning to vaguely understand. :)

This actually makes some sense to me: "This can happen with, say, a div floated to the right so it will be read afterwards, but coded into the page first so that the lefthand content, placed after it in the code, flows down alongside it and visually presents first."

Pinging Jroberson108 since he is working on this stuff here:

Wikipedia:Manual of Style/Accessibility/Data tables tutorial#Nested data tables.

--Timeshifter (talk) 17:39, 14 January 2024 (UTC)

I would stay away from using tables for layout purposes or oddly floated divs. These divs, however, don't use the float style and will always follow the one above it either to the right on wide screens or under it on narrower screens. The main purpose of the divs being used this way is to be responsive based on the screen size, something a table can't do.

I'm looking at these using Chrome on my Android phone in portrait orientation. For the divs, each box is 100% the width of my phone. On a wider screen, the divs appear next to each other reducing some of the white-space. For the table layout, the entire table is more than 100% the width and requires horizontal scrolling to see the whole table. On a wider screen, the table layout doesn't change. On a narrower screen the divs have less text wrapping than the table.

As I understand screen readers, they narrate left to right, top to bottom. For the divs, the entire code portion is read first followed by the entire output portion. For the table layout, because there are headers, there may be a bit more to read: headers first, then the code header and code portion, then the output header and the output portion. If the headers were emptied and moved into the code and output rows (no headers), then it would probably be less to narrate, but again not responsive and more text wrapping on narrower screens. Jroberson108 (talk) 18:57, 14 January 2024 (UTC)

I adjust the leftmost div with style=max-width:Xem; in these types of pairs. So that the leftmost div is not too wide on desktops. This way both the left and right divs can be responsive and fit on one line on a desktop, and even sometimes in landscape view on cell phones. That is if the rendered table in the rightmost div is not too wide.

I am about halfway through Help:Table in adjusting the leftmost divs to make the pairs more responsive. --Timeshifter (talk) 20:14, 14 January 2024 (UTC)

@Timeshifter: I usually omit the extra green border and padding on the div, which on mobile gives more width for content by reducing the left/right white-space and also reduces text wrapping. Jroberson108 (talk) 01:08, 15 January 2024 (UTC)

I just removed almost all the padding in the div pairs on Help:Table and in the above divs. That helped a little. Nearly all the white space has now been removed around the divs.

I tested removing the green border. That did almost nothing concerning removing white space since they are only 2 pixels wide.

The green borders help with clearly seeing the pairs. A single pixel is not nearly as good. The green really comes out with 2 pixels. A 1 pixel green border looks almost gray, and can be confusing when next to some of the gray table borders. So it helps with accessibility for people like me that don't like turning up their monitor too bright. That makes everything a little grayer. --Timeshifter (talk) 03:14, 15 January 2024 (UTC)

@Timeshifter: Remember, when the border is set to 2px, that's 4px total (left and right) extra width as well as a doubling of the extra padding on each div. To clarify, removing the border doesn't affect white-space, it would provide more space for content (less wrapping), and removing padding does both. You probably shouldn't rely on color to distinguish something from another and assume total color blindness would see it as a shade of gray similar to the borders that come with syntaxhighlight and tables (more at Color blindness), as you said you experience when you decrease your monitor's brightness. If there is an issue with confusing one border with another, you can play around with changing the border style from solid to dashed (see border), then color shouldn't matter. But, this does nothing for screen readers that would, in this case, rely on the headers above the code and table output, so proceed with that in mind. Jroberson108 (talk) 08:56, 15 January 2024 (UTC)

I did some screenshot viewing via this color blindness tool I like:

http://hclwizard.org:3000/cvdemulator

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.

--Timeshifter (talk) 03:38, 16 January 2024 (UTC)

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:

User:Timeshifter/Sandbox242

So I changed them all to inline-grid there at Help:Table. I think it helped, but I am not sure. There is still some wobbliness at times in portrait view. How about you? Is so, what could be causing it?

By the way, I changed to black div outlines to help accessibility for color-blind users. Red or green both end up being gray for some of them. Black is much more distinctive.

The 2-pixel black outline makes more of a difference in portrait view on cell phones. It is easy to get lost in that long column of stuff in portrait view of Help:Table. So when one sees the 2-pixel outline one soon learns that one is viewing a div pair. That is not always clear with a 1-pixel line. It is important for accessibility in the broader sense on cell phones. Though we are probably off topic in the traditional sense of accessibility. We should probably continue elsewhere. There is one accessibility question though:

Graham87, Moxy, etc.. Is the div pair higher up ("With divs") still accessible? They are now using display:inline-grid instead of display:inline-table. --Timeshifter (talk) 18:18, 17 January 2024 (UTC)

You already mentioned the border change in a previous post, which I said it looked better than what it was before. Not sure what "wobbliness" you are referring to? After the display style change, your sandbox and the Help page allow me to scroll wide tables when in that div. The only thing left pushing the page width on portrait is the big table at Help:Table#Table syntax comparison. It works if I remove the sticky, which isn't really needed on a table with two easy-to-remember column headers; also sorting isn't needed. Jroberson108 (talk) 20:06, 17 January 2024 (UTC)

I removed the sticky header there. I closed all the TOC sections of Help:Table and started down the page only opening one section at a time and looking for horizontal "wobbliness". :) Then I closed that section and opened another. This section seems like it can't stay in one horizontal position as I scroll through that section: Help:Table#More cell operations. Do you have the same problem there? If so, what do you think is causing it? I looked at the rest of the TOC sections and I don't see the problem in them. --Timeshifter (talk) 00:57, 18 January 2024 (UTC)

The large table scrolls correctly now. Still not sure what you mean by horizontal "wobbliness", which there is a clock image in that section and I can't help but think of Dr. Who, "Wibbly wobbly, timey wimey". Anyways, do you mean the page width gets pushed wider when you open the section and returns when closed? I opened and closed each section on Android Chrome and Firefox and had no issues. It might be the large table in the last sub-section at Help:Table#Individual cell borders. You might can copy the entire page to a sandbox and turn all the sub-sections into main sections and narrow it down that way. Otherwise, I don't have an iPhone, so you will have to get with someone who does. If further discussion about content is needed, maybe move to that talk page? Jroberson108 (talk) 01:48, 18 January 2024 (UTC)

Still fine with me as a screen reader user. Graham87 (talk) 03:48, 18 January 2024 (UTC)