Wikipedia talk:Manual of Style/Accessibility/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Archive 16

Archive 17

Relevant discussion of table legends and MOS:COLOR

Feedback requested at Wikipedia_talk:Manual_of_Style#Typographical_symbols_used_for_notes_and_accessibility. Thanks. ―Justin (koavf)❤T☮C☺M☯ 02:03, 21 March 2020 (UTC)

Coding help

Need help with advanced coding so we don't deter potential new editors because they can't see pages properly. Pls see Wikipedia talk:WikiProject Accessibility#Another module tutorial with accessibility problems.--Moxy 🍁 16:03, 7 April 2020 (UTC)

WCAG version

Our document says We aim to adhere to Web Content Accessibility Guidelines 2.0

Should we be developing to 2.0 or 2.1 of Web Content Accessibility Guidelines? 2.1 came out in June 2018 (new in 2.1). I took a quick glance in the archives and didn't see anything about this, apologies if I missed the discussion. Kees08 (Talk) 15:59, 7 April 2020 (UTC)

@Kees08: We should naturally strive to meet the latest version of the guidelines as a matter of course. Nevertheless, I'd be overjoyed if a significant proportion of editors made an effort to meet any WCAG guideline. --RexxS (talk) 23:24, 16 April 2020 (UTC)

Kees08, 2.1 for sure and update the language as the standard gets updated. ―Justin (koavf)❤T☮C☺M☯ 03:59, 23 April 2020 (UTC)

Okay, when I get time I will review the changes between 2.0 and 2.1 to make sure our documentation meets 2.1; when I (or someone) verifies that I will update it to 2.1 in the text. Kees08 (Talk) 15:55, 23 April 2020 (UTC)

Doing the more-or-less necessary review was why I snagged on just updating the guideline boldly. My brief skim of the changes looked like nothing of particular significance changed. --Izno (talk) 17:41, 23 April 2020 (UTC)

RfC on table captions

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There appears to be a consensus to add the language Data tables should always include a caption, particularly given the strong support from editors who use screenreaders. There was some discussion about tagging of non-compliant tables, and agreement to avoid any obtrusive tagging beyond potentially a maintenance category. the wub "?!" 21:39, 10 May 2020 (UTC)

---

Should tables always include a caption? --RexxS (talk) 21:41, 6 April 2020 (UTC)

Background

In most popular screen readers, it is possible to bring up a (voiced) list of all of the table captions on a page. That then allows the screen reader user to navigate directly to the table that they want to read.

As Graham87 has explained, if a table has no caption, then JAWS will voice the first column heading to 'identify' the table. We really should not be letting that happen, so there is an implicit expectation that a table will have a caption.

Graham also tells me that it's common for a screen reader user to navigate by calling up a list of headings and use that to navigate to the section that they want. That has lead us to accept tables without captions where the table comes immediately below a heading and the caption would simply duplicate that heading. That's a concession to sighted editors who don't like the look of repeated text – simply an aesthetic consideration. Nevertheless that still leaves screen reader users who navigate via tables with the issue of hearing the first column title instead of a sensible caption, so it's less than ideal.

I am requesting comments from editors with the intention to include a phrase along the lines of "Tables should always include a caption" in the guidance at Wikipedia:Manual of Style/Accessibility #Data tables if the RfC results in support for that. To be clear: this would mean that captions should be included in data tables, even when the table immediately follows a heading which would duplicate the caption. --RexxS (talk) 21:41, 6 April 2020 (UTC)

I've placed at notice at WP:CENT and at Wikipedia talk:WikiProject Accessibility. --RexxS (talk) 21:56, 6 April 2020 (UTC)

Please confine threaded discussion to the discussion section.

Support

1. To make life easier for screen reader users and to comply with H39: Using caption elements to associate data table captions with data tables. --RexxS (talk) 21:54, 6 April 2020 (UTC)
2. Thanks for opening this. Accessibility is more important than possible aesthetic concerns about "unnecessary" caption text, even if the table caption appears directly after a section heading. ~ ToBeFree (talk) 23:26, 6 April 2020 (UTC)
3. Accessibility is a concern that people who don't need, often take it for granted. We should do our best to fix any accessibility issue, and in this specific case, I support the proposal. Later on if we want to hide a caption visually when it's deemed redundant, technical minds can brainstorm possible solutions. Those solutions however, should come later and have no relation to this. --Gonnym (talk) 23:43, 6 April 2020 (UTC)
4. It's fine to add this. As with any MOS guideline, "occasional exceptions may apply". That covers the situations where headers shouldn't be used. NinjaRobotPirate (talk) 01:35, 7 April 2020 (UTC)
5. Support per above as a screen reader user. Graham87 01:48, 7 April 2020 (UTC)
6. Accessibility should take precedence over aesthetics, and I'm not even convinced that this is aesthetically undesirable. As a matter of good data presentation, tables should always have a caption just like figures. — Wug·a·po·des​ 03:35, 7 April 2020 (UTC)
7. Pretty much per all of the above. Accessibility is something that we should strive to continuously improve. OhKayeSierra (talk) 03:52, 7 April 2020 (UTC)
8. Support in principal, as long as we make clear in the language that Jonesy's concerns are addressed removing conditionality, I think in the rare case where a table clearly shouldn't have a caption, we can IAR --valereee (talk) 17:03, 7 April 2020 (UTC)
9. Support whenever it does not cause a bigger problem. · · · Peter Southwood ^(talk): 18:29, 7 April 2020 (UTC)
10. Support All tables should have captions and summaries. It strains my ability to assume good faith when editors who have sight think, "But I don't wannna see these three words again and a new line break!" at the expense of users who cannot see being able to navigate our site. The petty whining and minor inconvenience to those of us with vision is irrelevant when it comes to being accessibility. Accessibility is not negotiable. ―Justin (koavf)❤T☮C☺M☯ 20:04, 7 April 2020 (UTC)
11. Support per all the above. It's a small inconvenience for us in order to make tables quite a bit more useful to those who use screen readers. Ajpolino (talk) 22:20, 7 April 2020 (UTC)
12. Support. Since a template has been created to make such captions visible only to screen readers when they would be detrimental to the visual layout of a page, there is no reason not to use them. Seraphimblade ^{Talk to me} 00:27, 9 April 2020 (UTC)
13. Support....as many are aware I am one of those that use a screen reader from time to time when need be and rarely use a mouse. Accessibility for all should be our primary concern. Unfortunately it's not always so. As of late accessibility has not been a primary concern i.e February 2019 ATL text RfC (even our best articles don't have access for images) and Template:Welcome change to link Help:Introduction (a screen reader, TV box and non mouse nightmare). At least tables will be taken care of.... step by step.☺--Moxy 🍁 01:22, 9 April 2020 (UTC)
14. Support with the understanding that while a formal requirement, it should not be necessary for a new user to provide a caption to insert a table. We can flag it with a big ugly red warning rendered on the page like we do for ref/cite errors, which will tend to bring more experienced help along to fix it. But I just don't want this to keep someone from including a table when they otherwise wouldn't be able to if they couldn't figure it out. EllenCT (talk) 05:45, 9 April 2020 (UTC)
15. Support. I fully agree with Wugapodes, Seraphimblade, and EllenCT here. —⁠烏⁠Γ ^(kaw) │ 19:43, 09 April 2020 (UTC)
16. Support this sensible proposal. We can improve here, and telling people that they ought to include this is a sensible step towards improvement. WhatamIdoing (talk) 22:58, 9 April 2020 (UTC)
17. Support, for more than only screen readers (which is in itself a strong reason), but also because is tables can have associated captions we should do our best to (automatically) keep the captions with the tables, instead of in separate heading. With caveats as above, namely not having a caption is no reason to remove a table (but to add the caption), and this should be about tables with content, not all HTML tables. - Nabla (talk) 12:26, 11 April 2020 (UTC)
18. General support, but ... not "always" as written in the proposal. All readers should be able to access tables. I reject sighted readers decrying "readability" for other sighted readers—either be more creative and don't repeat captions in headers, or stop the long-standing mispractice of using headers for captions. Surely many of wrote a research paper at some point that included a list of tables or list of figures that placed the respective captions in the listings. Some oppose's bring up points which can be addressed by IAR.—Bagumba (talk) 15:10, 13 April 2020 (UTC)
19. Support absent any research that says table captions suppressed visually meet WCAG. If non-visible table captions meet WCAG, then I would reconsider. I do not agree with the oppose argument that since a majority of our users do not need accessibility, accessibility is unimportant. The aesthetics of a redundant table caption and section header is not even close to the importance level of making the page accessible for all users, regardless of disability. Redundancy can be mitigated by using table captions in lieu of section headers. If a section header is still needed, and the table caption would be redundant, and there is no possible prose to add, consider WP:NOTSTATS, which says Statistics that lack context or explanation can reduce readability and may be confusing; accordingly, statistics should be placed in tables to enhance readability, and articles with statistics should include explanatory text providing context. Although less ideal, there is of course no problem starting without a table caption and having it added later, but the argument that there are cases where a table caption should never be used (such as the cases that spawned this RfC) are unconvincing to me. Kees08 (Talk) 16:09, 15 April 2020 (UTC)
20. Support: aesthetics is second to usability, and I see some people who use screen readers supporting this proposal, and none opposing. The oppose section is one of the least convincing I've ever read, arguments which are variously factually incorrect, believe the solution lies in screen reading technology that would need to be as powerful as an AGI, or seem to think this proposal would be the only one on the site for which WP:IAR cannot be invoked. — Bilorv (talk) 17:16, 18 April 2020 (UTC)
21. Strong support as per everyone above me. I can't think of anything more to add. >>BEANS X2t 10:54, 20 April 2020 (UTC)
22. I am solidly in support here and do not find aesthetic arguments interesting, given the discussion around how assisting technology uses captions as well as the discussion regarding how formal writing is done (to wit, that you always include a caption for a data table, as you would a figure). (Heck, even normal web browsers or the MediaWiki developers might at some point provide a table of figures or a table of tables, which would be inhibited in the case that those items were not marked up reasonably.) --Izno (talk) 17:59, 20 April 2020 (UTC)
23. Support on the basis of what RexxS said to me in the discussion section below about tags or warnings not being added to articles that have tables without captions. If tags or warnings about that are added to any of the articles I maintain I will remove them.Smeat75 (talk) 18:47, 20 April 2020 (UTC)
24. Support Agree with above, esp. Gonnym, Wug·a·po·des, Serphimblade, and EllenCT. I worked as a documentation specialist for 17 years in software development. Some of our targeted output was HTMLHelp and Word. We were able to provide non-repetitive accessibility for table captions for both to screen readers. Nonetheless, this should be done as described for now until a better method is found. dawnleelynn^(talk) 16:42, 24 April 2020 (UTC) Additional comment. I've been thinking about this. You see, I've not been working in the field for a few years, so I have to let it come back to me. Back in 1997, working for Honeywell, we had this same issue with Word. The heading sections and the headers and the problem of duplicate headings. Plus, I was preparing these enormous documents for a program called HMTLTransit. HTMLTransit was to get them ready for HTML to put them on our Intranet. So, these issues of accessibility were being solved two decades ago. I only wish I still had the documents - it's too far back to recall how we handled it. dawnleelynn^(talk) 19:41, 24 April 2020 (UTC)

    Introducing the table to the reader is usually the primary way to do it in formal writing outside of Wikipedia (in some amount of verbiage). We don't do that often here (for some reason--perhaps we consider tables to be truly supplementary to our text). --Izno (talk) 19:51, 24 April 2020 (UTC)

    If you are saying we didn't have the issues we thought we had, were you there when we were putting documents into HTMLTransit? Have you ever used it? Have you ever seen a Honeywell flow chart control document? dawnleelynn^(talk) 20:38, 24 April 2020 (UTC) Oops make that a process flow control device manual. there. dawnleelynn^(talk) 20:55, 24 April 2020 (UTC)

25. Support. It is urgent that we come into compliance with WCAG to provide an accessible Wikipedia for readers and editors. --Bsherr (talk) 01:06, 27 April 2020 (UTC)
26. Support With the {{sronly}} template, there isn't even an aesthetic drawback to visual readers (in the case where the caption would duplicate a section header just above the table), so I see no reason to oppose adding this. --PresN 19:50, 1 May 2020 (UTC)
27. Support. Now I know this is an issue that exists I can't justify not fixing it, especially when the fix is so simple and so minimally disruptive. Thryduulf (talk) 09:20, 5 May 2020 (UTC)
28. Support. I think the benefit to those using screen-readers far outweighs the drawback of redundancy for sighted visitors. Schazjmd (talk) 22:23, 6 May 2020 (UTC)

Oppose

1. While I strongly support the principle of accessibility, I reluctantly oppose the RFC as written, since it is too broad and will lead to misunderstandings, misinterpretation, and ham-fisted implementations that please nobody. Wikitables are sometimes used for layout in situations where captions would be undesirable. I would much rather see an RFC or a discussion proposing specific changes to the wording at MOS:TABLECAPTION/MOS:TABLESUMMARY, which explain the subtleties of table captions and summaries. – Jonesey95 (talk) 23:47, 6 April 2020 (UTC)
2. Oppose Consider the effect on a topical page like 2019–20 coronavirus pandemic by country and territory. This has lots of tables and, in most cases, the section heading is used to introduce the table. Captions repeating this information would be redundant and attempts to make this look sensible might result in confusing workarounds. This indicates that the issue is best addressed on a case-by-case basis rather than by a blanket rule. Also, it appears that there's a summary attribute in HTML4 which is provided to explain tables in screen readers. That was deprecated in HTML5 but the technical alternative seems unclear or half-baked. This aspect should be clarified. Andrew🐉(talk) 08:09, 7 April 2020 (UTC)
   • Andrew, that article has had captions on all the tables for the last two days, and I don't see any complaints about it. WhatamIdoing (talk) 23:05, 9 April 2020 (UTC)
3. Generally? Yes. Always? No. Both those above articulate good reasons why. — Godsy ^(TALK_CONT) 17:21, 7 April 2020 (UTC)
4. Oppose while this is likely helpful and useful for most tables, I think we have to be more nuanced than a general rule, which will not be suitable for all uses of tables on Wikipedia. buidhe 18:40, 8 April 2020 (UTC)
5. Oppose This MOS point was written in a way that simply does not jive with the way tables are often used in practice, particularly template-based, dynamic tables. Consider 1901 Michigan Wolverines football team#Schedule where Template:CFB schedule is used and Fielding H. Yost#Head coaching record where Template:CFB Yearly Record Start is used. In both cases, preceding section headings introduce the topic of the table, as is standard practice for thousands, even tens of thousands, of analogous instances in other articles across the encyclopedia. Jweiss11 (talk) 15:12, 9 April 2020 (UTC)
6. Oppose - This is overkill. I understand the need for accessibility, but in general practice, a table does not require a title and shouldn't require one just because screenreaders aren't capable of deciphering the page without one. If that is a problem, it's something to be solved at the screenreader's end, not ours. – PeeJay 23:10, 12 April 2020 (UTC)
7. Oppose as above. Good intentions re:accessibility, but this is overkill and will actually hinder navigation/readability for the vast majority of readers who don't need screen readers. GiantSnowman 14:21, 13 April 2020 (UTC)
8. Oppose - seems to me overkill. It creates problems if adopted as a rule for tables that don't need labels or a perfeectly comprehemsible as they stand: e.g. the 'roles' table used almost universally on opera articles where the headings make it clear what it is about. I do think we can trust the reader!--Smerus (talk) 09:07, 19 April 2020 (UTC)

   Oppose - on the same basis as Smerus. I also work on opera articles a lot, this proposal seems to assume that WP has an army of volunteers ready to leap into action at this RfC's command and spend hundreds of hours going through thousands of articles doing the fiddly format fixing called for. I don't see that happening but I can well imagine, as someone says above, people happy to slap big ugly red warnings on all these articles THIS TABLE HAS TO HAVE A CAPTION. Smeat75 (talk) 19:54, 19 April 2020 (UTC)

Discussion

As I said above, I reluctantly oppose this RFC as worded too broadly. Template:Navbox, for example, uses table markup, but unless I am mistaken (which happens regularly), it provides neither a caption nor a summary. How would our navboxes be modified to have a caption? If this is a straw man, feel free to set it on fire; I'm just looking at what comes out of Special:ExpandTemplates when I put Template:AKB48 or pretty much any other navbox in it. – Jonesey95 (talk) 23:51, 6 April 2020 (UTC)

@Jonesey95: I had hoped my introductory statement made it clear that I was proposing an amendment to the section Wikipedia:Manual of Style/Accessibility #Data tables, which deals with data tables, and not to the section Wikipedia:Manual of Style/Accessibility #Layout tables, which deals with layout tables. That section states

When using a table to position non-tabular content, help screen readers identify it as a layout table, not a data table. Set a role="presentation" attribute on the table, and do not set any summary attribute. Do not use any <caption> or <th> elements inside the table, or inside any nested tables.

so I really don't think this RfC can possibly have any bearing on the use of tables for layout. --RexxS (talk) 00:07, 7 April 2020 (UTC)

Please change the wording of the RFC, and similar to an edit request, provide a clear "Change X to Y" showing what you propose as before and after text on this MOS page. Ambiguous RFCs have a bad habit of being misinterpreted. I'm happy to change my support/oppose position once the RFC's wording matches your intent. – Jonesey95 (talk) 00:08, 7 April 2020 (UTC)

This isn't an editprotected request: please read WP:RfC. I wrote "I am requesting comments from editors with the intention to include a phrase along the lines of "Tables should always include a caption" in the guidance at Wikipedia:Manual of Style/Accessibility #Data tables" and I don't think that could be any clearer. I won't try to persuade you to change your opposition, as it should be sufficient for the closer of the RfC to determine the community's consensus on what wording would be appropriate and the context to which it applies. --RexxS (talk) 00:33, 7 April 2020 (UTC)

If the desired wording is "Data tables should always include a caption", that is what the RFC should ask, and what the proposal tucked into the Background section should say. – Jonesey95 (talk) 14:58, 7 April 2020 (UTC)

That's what the proposal in the Background section does say: it applies to the Data tables section of this guideline. There's no such thing as a caption in a layout table. --RexxS (talk) 18:12, 7 April 2020 (UTC)

@NinjaRobotPirate: Hi, I was wondering if there were any specific exceptions that apply that you were thinking of. I am sure there could be exceptions, but I was hoping we could clear up if a similarly worded section header directly above the table could be considered an exception. Did you mean that case, or other exceptions we may not be thinking of? I suppose the proposal is clear, as it says To be clear: this would mean that captions should be included in tables, even when the table immediately follows a heading which would duplicate the caption, but I wanted to make sure you saw that. Thanks! Kees08 (Talk) 15:42, 7 April 2020 (UTC)

• RexxS, Is there no way to provide an invisible caption, like the alt text for an image? · · · Peter Southwood ^(talk): 18:33, 7 April 2020 (UTC)
  • @Peter: the alt text is not really invisible, per se, but browsers are programmed to only display it when images are switched off, while screen readers will always voice it. What we would have to do is find some way of making sure that a screen reader reads the caption text, while ensuring that a browser doesn't show it.
    One suggestion was to make the colour of the text the same as the background, but that goes wrong when readers use background colours different from the usual. There's no guarantee that different pages or skins have the same (I also know one visually impaired user who has used custom high-contrast inverted colours - white text on a black background).
    The best suggestion I've seen so far is at https://cloudfour.com/thinks/see-no-evil-hidden-content-and-accessibility/#showing-additional-content-for-screen-readers but it's complex and requires a certain degree of browser compliance. Effectively it places the text inside a 1px square and tells the browser not to display any content inside and outside of it. A screen reader ignores those display directives and will still read the text as normal. Anyway, we won't need tech solutions to problems of hiding duplicate text until we start requiring captions for all data tables. --RexxS (talk) 19:34, 7 April 2020 (UTC)
    • If the display could be suppressed then duplicating the headings would not be a problem, which would eliminate one reasonable objection. · · · Peter Southwood ^(talk): 19:52, 7 April 2020 (UTC)

  Pbsouthwood, If you don't want to see them, you can edit your personal CSS to mark the tag caption as nodisplay. ―Justin (koavf)❤T☮C☺M☯ 20:06, 7 April 2020 (UTC)

  (edit conflict) @Koavf: It really does not bother me enough to do that, and I would actually be more likely to use css to make them visible for me if they were invisible by default, so I could see where they were missing and fix that, but it can look a little sub-optimal from a purely aesthetic point of view, and it is nice to have options. Accessibility is more important, I agree. · · · Peter Southwood ^(talk): 20:21, 7 April 2020 (UTC)

  (edit conflict) @Peter: I've created Template:Sronly that uses template styles to hide its content from browser display, while leaving it available for a screen reader to voice. There's an example in the template documentation of a table immediately below a level-3 heading with the same content as the caption. It's not perfect because the 'clip' property is deprecated and I haven't tested it in different browsers yet, but I thought you might be interested in a the first draft. Cheers --RexxS (talk) 20:11, 7 April 2020 (UTC)

  @RexxS: That is exactly the sort of functionality I was thinking of. If it can be made to work reliably... · · · Peter Southwood ^(talk): 20:28, 7 April 2020 (UTC)

  If it works, I'm all for it as that is what I was suggesting at Template talk:CBB yearly record start#Captions are necessary. Sometimes, the duplication gets take to high levels as I previously pointed out at Indianapolis Colts#Statistics and records having a subsection titled Season-by-season record, and a table caption of Indianapolis Colts season-by-season records, leading to three displayed titles all in row describing the same thing. If there was a function to insert invisible captions to every table (you could even theoretically make it a required function something like the wikitable template) than a great many arguments could be solved. Yosemiter (talk) 22:22, 7 April 2020 (UTC)

• @Andrew Davidson: It might be stylistic preference, but I would remove the subsections in Entities without confirmed cases and leave the table captions. In that case we are using sections as both the table caption and to contain the table. For the Timeline of first confirmed cases by country or territory section, I would write a short introduction of where it started and initial spread, and the most recent to be confirmed (which of course would need updated regularly). I don't mean to nitpick your example article, and maybe there has been discussion on the talk page I did not see related to these suggestions, but it seems like table captions duplicating section header wording can be easily avoided in at least some scenarios. Kees08 (Talk) 16:59, 9 April 2020 (UTC)

  User:Kees08 might try his ideas out and let us know how he gets on. Note that, per WP:NOTLAW, we should not be making prescriptive rules which do not correspond to generally accepted practise. Andrew🐉(talk) 17:13, 9 April 2020 (UTC)

  @Andrew Davidson: Using table captions is generally accepted practice and guidance on all major websites comparable to Wikipedia. The fact that Wikipedia is written by a multitude of editors, many of whom are unaware of the consequences of their edits to readers with disabilities, should not result in poor practice enduring. Anyone who becomes aware of the value of table captions to screen readers should be able to add captions and, where necessary, quote our guidance requiring them. Experience tells me that's the only way to make progress on accessibility issues on Wikipedia. --RexxS (talk) 17:53, 9 April 2020 (UTC)

  @Andrew Davidson: What do you think that Web Content Accessibility Guidelines are then, if not a generally accepted practice? --Redrose64 🌹 (talk) 19:49, 9 April 2020 (UTC)

Outside of Wikipedia, I assume that formal papers generally expect tables to have a caption. My guess is in WP that

1. Few examples exist in WP articles that use table caption to copy from, and people don't bother looking at Help:Table
2. Everybody knows header syntax, and use that instead as a (crude) caption workaround

Now that people are realizing the accessibility issues, some might be reticent to reword (or remove) those legacy headers that would sound repetive by adding the table captions (that ideally would have been used to begin with). Preferably, we would address accessibility while minimizing the effort to retrofit headers. For example, Eagles247 and Koavf found a way for {{NFL roster}} at User_talk:Koavf/Archive055#Template:NFL_roster to retrofit an existing template to move existing display text to the caption with no visual difference for sighted readers. This is not always possible, depending on the template.—Bagumba (talk) 17:29, 9 April 2020 (UTC)

The oppose from Jweiss11 typifies the flawed argument "We've been ignoring the needs of the visually impaired for years, so we should be free to carry on doing it." There's no recognition that aesthetic issues such as a caption repeating a header are very minor compared to the need for screen reader users to have a sensible way of navigating to a particular table. Consider 1901 Michigan Wolverines football team#Schedule where editors leave screen reader users to identify that table as "Date". There's absolutely no reason why Module:CFB schedule should not add a caption tag at line 360. Consider Fielding H. Yost#Head coaching record where screen reader users need to navigate to the table called "Year". How unhelpful is that? What does it really matter if we take the trouble to put "Head coaching record" as the heading and the table caption? Would the table even need its own section if the table had a proper caption? --RexxS (talk) 22:56, 9 April 2020 (UTC)

RexxS, a table heading of "Schedule" immediately following a section heading of "Schedule" seem very redundant. Redunantly redundant even. :) If you don't put the head coaching record table in the Yost article in its own section, where would you put it? To avoid the section–table redundancy problem, have to put the table inside another section that also contains other substantive content, likely significant prose. I suppose that could be done, but there we are talking about it a restructuring of tens of turnarounds are articles. Maybe hundreds of thousands. Has anyone explained why we can't have a field just for the screenreaders to solve this problem without creating redundant text in the standard displays? It would also be helpful if a screen reader user could describe his or her whole experience of encountering a table like the head coaching record table at the Yost article, taking us through the approach to the table from the preceding heading and then cell to cell through the table. Are there any free screenreaders out there people find reliable? I think it would helpful for many of us to play around with them. Jweiss11 (talk) 23:16, 9 April 2020 (UTC)

@Jweiss11: There's no such thing as a "table heading". There are section headings and table captions, and they serve very different purposes. A heading of "Schedule" is for sighted readers to observe a change of topic from the preceding content. A table caption of "Schedule" is for screen reader users to navigate to the table they are interested in as explained in Background section above. Is it "redundant" to give screen reader users a way to sensibly identify the table so that they can navigate to it? What is the other way of identification that makes the caption redundant?

If you chose to remove the "Schedule" heading from the Yost article, what would be lost? The table with a caption of "Schedule" would still be in the same place, although personally, I think it should be part of the Coaching career section, rather than stuck on the end of the article as if an afterthought.

Why does the size of a task that improves articles for the disadvantaged represent a barrier to doing it? Is it really a good argument to say "I would need to improve thousands of articles, so I won't make a start with one"?

"Has anyone explained why we can't have a field just for the screenreaders to solve this problem without creating redundant text in the standard displays?" There are no fields. The caption text is not redundant, and there are no standard displays. For the blind, there are no displays at all. If you read the discussion, you'll find that I already created a template Template:Sronly that seems to be able to instruct modern browsers not to display a piece of text, while allowing screen readers to voice that text.

You can always ask Graham87 relate his experiences to you, but what you're asking for has been rehearsed many times in discussions about accessibility. Alternatively you can read HTML Tables with JAWS, part of the manufacturer's manual for the JAWS (screen reader), probably the world's most popular screen reader.

NonVisual Desktop Access (NVDA) is a popular, free, open-source screen reader for Microsoft Windows. Category:Free screen readers gives a few notable alternatives. Cheers --RexxS (talk) 23:47, 9 April 2020 (UTC)

RexxS, thanks for the info on screen headers. By "table heading" I meant the table's caption. And by "standard display" I meant any of the common visual renderings. I'm particularly curious how a screen reader will vocalize an endash in a table, because an endash can mean a few different things based on context. Thanks also for creating Template:Sronly. That may be the solution here.

If I was sure that we were about to embark on the improvement of thousands of articles, I would have no reservations. But I feel we are about to do "something" to thousands of articles that may require serious man-hours for what may not be a net improvement. So we should think carefully now. Going back to the Yost article, if you remove the "Schedule" heading, two negative things happen. First, you remove a link to the record table from the table of contents, and that is precisely the sort of content a reader would likely want to jump to. Second, you break up the prose of the article with a very long table. This comprises the accessibility of the article for visual display users, the vast majority of readers. Things with tables get even more complicated for articles like Phog Allen, which has two parallel record tables, one for each of two different sports. Jweiss11 (talk) 00:31, 10 April 2020 (UTC)

@Jweiss11: Screen readers by default generally pronounce an en dash as "dash" in all situations, which is quite acceptable. Graham87 06:19, 10 April 2020 (UTC)

@Jweiss11: For "Schedule" in a team season article, the table caption could be "Results". For example in 2019–20 Michigan Wolverines men's basketball team, the current header is "Schedule and results", so just make "Results" the caption and "Schedule" the header. For biographies, the stats section header could be a generic "Statistics", regardless with they were a coach, player, or both. Table captions could then perhaps be "Head coaching career", "College playing career", "NBA playing career", etc.—Bagumba (talk) 12:43, 11 April 2020 (UTC)

I see a similar dilemma with the section/table "Roles" in standard opera articles (eg see Eurydice (Aucoin)). What would be a non-distracting and non-redundant table caption for those? -- Michael Bednarek (talk) 13:19, 17 April 2020 (UTC)

In that particular one, it seems that "Premiere cast, February 1, 2020" would be better as a caption than placed in the header for the performers' column. As an aside, the existing section header of "Roles" is already redundant.—Bagumba (talk) 15:51, 17 April 2020 (UTC)

I don't understand what you mean. Why is the section header of "Roles" "already redundant"?Smeat75 (talk) 20:40, 19 April 2020 (UTC)

I meant that the section header was "Roles", and then the first table column had header of "Role".—Bagumba (talk) 14:18, 21 April 2020 (UTC)

That would be the case if we knew that all screen readers did the same as JAWS and dropped back to the first column header, but I don't know how common that behaviour is. Nevertheless, I would still use "Premier cast" as a far better identifier of that particular table. If I were a screen reader user returning to that article and wanted to navigate directly to that table, I'm pretty sure I'd remember it as a table telling me the premier cast, rather than simply roles. That's the strategy I try to use when writing captions. --RexxS (talk) 17:59, 22 April 2020 (UTC)

In the area of WP I edit which uses tables the most, many, many, MANY of them,opera, in WikiProjectOpera we are already discussing how to change our guidelines to add captions to these role tables "In line with the 2020 RfC on table captions to aid accessibility for those using screen readers, role tables going forward should have an incorporated caption" (emphasis added) [1] No one has expressed any interest in going to already existing articles and adding captions to the HUGE numbers of tables in them though, quite the opposite.Smeat75 (talk) 18:28, 22 April 2020 (UTC)

I am not arguing for or against, but out of curiosity, has anyone found good information on if it is generally accepted practice to hide table captions? I imagine this is not the first time this has been discussed on the internet, so if I can read other articles/discussions/specifications that give the pros and cons to doing so, it would help me form an opinion on visibility. I tried a cursory search yesterday and did not find anything particularly useful. Kees08 (Talk) 19:00, 10 April 2020 (UTC)

Can this proposal be changed to "As from 1 May 2020 (or some other date in the near future) any data table in a newly-created article or any new data table added to an existing article should include a caption?" If so, I would support it. If it just says "tables should always include a caption" as the question is framed, that means virtually every article on individual operas is going to be non-compliant, thousands and thousands of them, as they almost all have role tables, and as Jweiss11 says, maybe tens of thousands of articles on sport. I don't know who it is imagined will take the trouble to go through this enormous backlog and add captions to huge quantities of tables. But I can well imagine MOS or technical zealots who would go through all these thousands? tens of thousands? hundreds of thousands? millions? of articles and deliberately make them ugly, as EllenCT suggests above, by flagging them with a big ugly red warning rendered on the page like we do for ref/cite errors. I think that would be absolutely intolerable.Smeat75 (talk) 15:08, 20 April 2020 (UTC)

That isn't how guidelines work. There no is no "this rule should be followed, unless you are one of the 6,931,109 articles created before. Look again at that number before you ask for an exception. --Gonnym (talk) 15:21, 20 April 2020 (UTC)

Then I am completely opposed to this proposal. Smeat75 (talk) 15:34, 20 April 2020 (UTC)

It is disappointing to see experienced editors creating strawman arguments against improving our articles for the benefit of the visually impaired. What is clear is that many thousands of articles make it difficult for anyone using a screen reader to navigate to the appropriate table in that article. That needs to be rectified, and the way to do it is not by ignoring the problem, but by educating editors into better editing practices to improve the experience for disadvantaged readers. There is no doubt whatsoever that adding captions to tables improves that experience, and editors ought to be seeking ways of enabling that process, rather than trying to place needless barriers in its way.

There is no proposal to make articles ugly or to slap any sort of big ugly red warning tag on them. That is pure scaremongering. We have a similar problem with the lack of alt text, but there is not a single article on Wikipedia with a tag saying "THIS IMAGE NEEDS ALT TEXT", despite the requirement for alternative text having been part of the MoS for years. If it were felt helpful to identify articles with tables that needed captions, the correct way to do that would be to create a maintenance category and allow our wiki-gnomes to work from that. Anybody who does that sort of routine editing, such as using AWB, will tell you that a category is the best starting place. There is no problem with this proposal, and all of the objections so far have been based on faulty premises or non-existent arguments. --RexxS (talk) 16:25, 20 April 2020 (UTC)

There is no proposal to make articles ugly or to slap any sort of big ugly red warning tag on them- but that's what EllenCT suggests above. It's an exact quote. She says a table without a caption could be flagged with a big ugly red warning rendered on the page like we do for ref/cite errors. That's what I find alarming. If it were felt helpful to identify articles with tables that needed captions, the correct way to do that would be to create a maintenance category and allow our wiki-gnomes to work from that - if it were clarified that was the way to proceed and that on no account were tags or warnings to be placed on articles I would change my opposition to support.Smeat75 (talk) 17:07, 20 April 2020 (UTC)

Smeat75, grandfathering in older articles as exceptions doesn't really work for technical reasons either because many articles—old, new, and yet-to-be created—have or will have their tables rendered via long-standing templates. Jweiss11 (talk) 16:36, 20 April 2020 (UTC)

@Smeat75: I'm afraid that EllenCT is mistaken. Cite errors are not an accessibility concern, and the author of the family of Module:Citation modules built that error message system into the module itself. There is nothing remotely comparable with table captions, which never requires anything more than writing a simple phrase identifying the table for screen readers in one line of each data table. The way that captionless tables could be identified would be by using a bot to find them. For all the reasons you elucidate, nobody would support a request for such a bot to slap big red warnings on those articles, especially when it is equally simple (and far more useful) to add a hidden maintenance category. I don't have any authority to guarantee anything to you, but you do have my assurance that I would be arguing just as strongly as you to keep "shame tags" out of our articles. If I'm to make my wiki-life easier, I'm sure you can see that I need to engage, not alienate, established content editors such as yourself in the process of making accessibility improvements to our articles. --RexxS (talk) 17:33, 20 April 2020 (UTC)

Why is ugly bad? and similar inline tags are ugly, as are big warning amboxes. If they weren't ugly, volunteers would be less inclined to improve them. Ugly is far less important than inaccessible to screenreaders for the blind. EllenCT (talk) 00:00, 21 April 2020 (UTC)

Rather than deliberately deface who knows how many articles by making them ugly in order to coerce volunteers to do what you feel is needed, just do it yourself. It would be a better use of your time to add captions to the tables that need them.Smeat75 (talk) 01:56, 21 April 2020 (UTC)

@EllenCT: One of the problems with trying to improve articles' accessibility is that we get pushback from editors curating articles who don't see the value in the changes because, for example, they have no experience of using a screen reader. My experience over the years has been that trying to push harder just increases resistance. IMHO, what works best is to try to accommodate the objections where we can. I've gone to the trouble of making a template, {{sronly}}, that hides captions from normal view while allowing screen readers to voice them. That template doesn't improve accessibility, per se, but it overcomes the objections that seeing similar text twice is unaesthetic/redundant/etc. Similarly, when we systematically identify tables without captions, we could add a tag (but we know that isn't wanted by several editors), or we could add the article to a maintenance category (which upsets no-one but is as effective). In the long run, the more we can take editors with us in the mission to improve accessibility, the easier the task becomes. — Preceding unsigned comment added by RexxS (talk • contribs) 18:12, 21 April 2020 (UTC)

FWIW I oppose the use of {{sronly}} unless someone can show it meets the web accessibility guidelines. I appreciate your effort in making it, but if it doesn't meet the web accessibility guidelines, we shouldn't use it. Kees08 (Talk) 18:52, 21 April 2020 (UTC)

@Kees08: Which web accessibility guideline do you want it to meet? I think the onus has to be on you to show a case where it doesn't meet a guideline, not for me to show that its use meets all possible accessibility guidelines in all possible cases. If you want to know whether common screen readers voice the text inside the template, you only have to try it yourself using a free screen reader. The example at Template:Sronly works when I try it. --RexxS (talk) 17:50, 22 April 2020 (UTC)

@RexxS: I was concerned about meeting WCAG 2.1 Success Criterion 1.3.1. Their suggested technique (techniques defined here) is H39, which says 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). Since we are deviating from the default display of captions from the suggested technique, I was hoping we could put our evaluator hat on to make sure it still meets the success criterion (I posted a bit about it above that was unanswered, it got buried). I have concerns about hiding it unrelated to accessibility, because it encourages poor sectioning and placement of tables, but I suppose that's a discussion for a different venue since this is a MOS proposal for accessibility. Kees08 (Talk) 16:28, 23 April 2020 (UTC)

@Kees08: Okay. I understand that concern, which is that captions may be hidden from sighted viewers inappropriately. At present, we require data tables to have captions, but we accept a situation where tables have no caption when the caption would effectively duplicate an adjacent heading. For those circumstances, we are now proposing to add a caption for the benefit of screen readers. However, where the caption duplicates the adjacent heading, there is no need for a sighted reader to see that caption, so it would not breach WCAG 1.3.1 to hide it from sighted readers.

Nevertheless – and this is what I think is the nub of your concern – whenever a table has no adjacent heading that would duplicate the caption, there is a need for sighted readers to see the caption (and WCAG 1.3.1 requires it).

I've updated the documentation at Template:Sronly to make it clear that the template is only for use to hide captions when it would duplicate the adjacent heading. I can't force editors not to misuse templates, but perhaps having explicit instructions on its use will help to avoid breaches of WCAG 1.3.1. Cheers --RexxS (talk) 17:34, 23 April 2020 (UTC)

@RexxS: Thanks. When I took the second look at it I better understood how the guidelines were structured, so it was a useful exercise for me. I had misremembered how the RfC was proposed; I thought it had specific wording to include. As long as To be clear: this would mean that captions should be included in data tables, even when the table immediately follows a heading which would duplicate the caption is clarified a bit to say something along the lines of When there is no prose between a section header and table, Template:Sronly should be used it should be fine. It does not need to be rephrased in the RfC now, I think it is reasonable to include that wording in the MOS update. Cheers. Kees08 (Talk) 17:51, 23 April 2020 (UTC)

@Kees08: As with all Wikipedia content, the wording from an RfC is not set in stone. In particular, the addition of clarification which has arisen during discussion is almost invariably uncontroversial. Perhaps one of us can ask the closer to make an explicit recommendation along those lines? Cheers --RexxS (talk) 17:59, 23 April 2020 (UTC)

I wanted to take Gonnym's comment a slightly different direction. When we change policies and guidelines, that doesn't magically add some sort of demerit badge to all of the articles which are no longer 'compliant', it just means we need to change those articles to be better articles. (Never mind the concerns of big_red_errors that RexxS is making clear are unfounded.) However, it does usually mean that users can be asked not to revert changes making them compliant (without sufficient reason). It's just another improvement among many that users can and should make to a wiki page at the end of the day. --Izno (talk) 17:52, 20 April 2020 (UTC)

Closure

The RfC will expire within 48 hours, and is probably ripe for closure anyway. I suggest that we ask an uninvolved administrator or experienced user to close this RfC as the question poses a significant change to prior practice.

Should the RfC result in support for the question, I would like the closer to confirm a form of words for the guideline that best represent the consensus expressed in the debate. My suggestion would be adding the following sentence to the end of the Caption section in Wikipedia:Manual of Style/Accessibility #Data tables:

• Data tables should always include a caption.

I suggest that anyone should feel free to suggest alternative wording, but please don't re-legislate the entire discussion. We should be trying to help the closer, not convince them of our own view. Cheers --RexxS (talk) 22:40, 4 May 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A quick follow-on related to this: I noticed that the default "insert table" button in the wikitext editor does not include a caption element by default, and have filed phab:T252350 so that new tables added this way are encouraged to include a caption. The VisualEditor insert table option does already include space for a caption. the wub "?!" 21:54, 10 May 2020 (UTC)

@Pete: thank you! Every little bit of improvement to accessibility helps makes the Wikipedia experience more tolerable to disadvantaged users. Well done to the VE devs. Cheers --RexxS (talk) 22:05, 10 May 2020 (UTC)

Only use the small tag for semantic purposes?

This addition does not seem useful to me. It moves from accessibility advice into style advice, and small tags are useful for reasons other than semantic purposes, like shrinking the second line of an infobox title (larger by default) so that it shows as normal-sized text. I'm sure there are other examples. – Jonesey95 (talk) 22:48, 16 April 2020 (UTC)

<small> is HTML small, which has the meaning added in the edit in question. If you want to make things small for another reason, you should use {{small}} or {{font}}. --Izno (talk) 22:59, 16 April 2020 (UTC)

OK, I guess, but that is incredibly obscure and unenforceable, so I don't see the point of putting it in at all. And again, this is the accessibility section of MOS. Perhaps the text should go at MOS:FONTSIZE instead, and it should provide helpful guidance instead of just a prohibition, perhaps something like "if you want to make text smaller without indicating that it is a side comment of secondary importance, use {{small}} or {{smalldiv}}, as appropriate." – Jonesey95 (talk) 23:19, 16 April 2020 (UTC)

Jonesey95, All tags should be used for semantic purposes. Give me an example of an HTML tag that is not obsolete and is stylistic rather than semantic. Why are you trying to use HTML for style? ―Justin (koavf)❤T☮C☺M☯ 23:33, 12 May 2020 (UTC)

I'm not saying that I am trying to do anything. I'm saying that guidance about HTML tags belongs in a different section of MOS, and I wish you luck. – Jonesey95 (talk) 01:14, 13 May 2020 (UTC)

Jonesey95, lol, thanks for those kinds words! So helpful! ―Justin (koavf)❤T☮C☺M☯ 04:46, 13 May 2020 (UTC)

transliteration example

At Wikipedia:Manual of Style/Accessibility#Text there is guidance on transliterations:

Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.

It's not clear how to do this. It would be very helpful if there were examples. For instance, should the transliteration appear following the non-Latin text and appear in parentheses? Coastside (talk) 19:43, 13 May 2020 (UTC)

Thanks for the note. I've added links to relevant templates. Graham87 04:50, 14 May 2020 (UTC)

Images that use fixed sizes, in galleries, in tables

Do things like UEFA Euro 2020#Venues cause problems? First, they're fixed size. Second it's a type of gallery. Third, they're in oddly formatted tables. Fourth, no alt text. Walter Görlitz (talk) 18:27, 18 May 2020 (UTC)

That looks like a strange way of creating a gallery. That should just be a gallery, with the text of the 3 rows being it's caption. --Gonnym (talk) 18:41, 18 May 2020 (UTC)

(edit conflict) Principally, the table is going to be completely incomprehensible to a screen reader when it's serialised. It's clearly a layout table being used to display 12 individual tables and a map, but with the markup totally muddled between the two roles. It would be suitable for a printed brochure, but not for an encyclopedia. It's a real mess when viewed on my mobile phone as well. The rest of the issues (fixed size images, lack of captions and alt text) are also real, but pointless to worry about until the layout is fixed. --RexxS (talk) 19:16, 18 May 2020 (UTC)

It's quite common in association football tournament articles. See the remainder of the Euro tournaments, FIFA World Cup tournaments, and others. Any solutions? Walter Görlitz (talk) 19:26, 18 May 2020 (UTC)

This should be saved somewhere as an example of what not to do.--Moxy 🍁 19:28, 18 May 2020 (UTC)

@Walter Görlitz: the layout can't be kept when over half the viewers will have to scroll horizontally on their phones to get the information. Personally, I'd take the map out and put it somewhere separate, nearby. Then I'd convert the remainder into to a list of 12 tables and use CSS on a container div to display them flexibly:

English Venue

London
Wembley Stadium
Capacity: 90,000

German Venue

Munich
Allianz Arena
Capacity: 75,000

Italian Venue

Rome
Stadio Olimpico
Capacity: 72,698

Azerbaijani Venue

Baku
Olympic Stadium
Capacity: 68,700

Russian Venue

Saint Petersburg
Krestovsky Stadium
Capacity: 68,134

Hungarian Venue

Budapest
Puskás Aréna
Capacity: 67,215

Romanian Venue

Bucharest
Arena Națională
Capacity: 55,600

Dutch Venue

Amsterdam
Johan Cruyff Arena
Capacity: 54,990

Spanish Venue

Bilbao
San Mamés
Capacity: 53,332

Scottish Venue

Glasgow
Hampden Park
Capacity: 52,063

Irish Venue

Dublin
Aviva Stadium
Capacity: 51,700

Danish Venue

Copenhagen
Parken Stadium
Capacity: 38,065

There's probably already a template to create the containers. The problem you'll get is that it doesn't look as pretty on a desktop display. Miles better for a screen reader and on mobile though. --RexxS (talk) 21:39, 18 May 2020 (UTC)

Thanks. I had my suspicions about it in the past. Care to drop this on the WP:FOOTY project? Walter Görlitz (talk) 21:56, 18 May 2020 (UTC)

Sorry, Walter, I'm up to my armpits in crocodiles already without taking on another fight right now. --RexxS (talk) 22:09, 18 May 2020 (UTC)

Understood. I'll see if I can mention it to them, but seeing how poorly they understand the roster layout issue (see Template talk:Football squad player), I'm not sure they're ready to be open to more accessibility changes. Walter Görlitz (talk) 01:00, 19 May 2020 (UTC)

Table header order

There is an rfc on the layout of tables listing adult entertainment awards, and I recognised an accessibility issue with the reading order of the table headers for a screen reader.Wikipedia_talk:WikiProject_Pornography#rfc_49102E2 I referred to WP:ACCESSIBILITY, but then realised there is no advisory on headers and reading order in the section about data tables for people to refer to. Morbidthoughts (talk) 07:51, 20 May 2020 (UTC)

Rowspan and screen readers

I'm not sure where I read it, but I read that there were issues with some screen readers and tables that used rowspans. Has this been resolved or are we even seeking resolution? They are heavily used in articles about musicians and sportspeople. I'm curious if we should be approaching those projects or if a larger consensus needs to be reached. Walter Görlitz (talk) 06:30, 12 May 2020 (UTC)

Also, does the {{na}} have enough contrast when used in a table? What of the other templates associated with it? Walter Görlitz (talk) 06:32, 12 May 2020 (UTC)

Rowspans are fine to use with major screen readers these days. Graham87 18:51, 12 May 2020 (UTC)

@Walter Görlitz: When I wrote User:RexxS/Accessibility ten years ago, we were asked by RNIB to test webpages with the Lynx text-only browser as a proxy for what a visually impaired user might experience. In the ensuing decade, the use of dedicated screen readers has grown and their capabilities expanded considerably. As Graham says, all but the oldest screen readers will cope with just about any uses of rowspan. I should add, though, that very complex tables with multiple different rowspans crossing different columns can make navigation more difficult for a screen reader. As long as the table has a straightforward layout, though, that shouldn't be a problem to worry about.

The template {{na}} has background #ECECEC and foreground #2C2C2C and that passes Snook's colour check in every aspect at AAA level. Sadly, I can't say the same for a number of the other templates noted in the documentation, with {{incorrect}} and {{shade|75%}} being obvious culprits. --RexxS (talk) 19:58, 12 May 2020 (UTC)

Thanks. I've been remove rowspans for some discography sections and will attempt to reverse that now. I sure wish I could remember where that discussion occurred. Walter Görlitz (talk) 04:15, 13 May 2020 (UTC)

• Thank you Walter Görlitz for this thread - I like Walter was told rowspans affected screenreaders badly and therefore this year made it my mission to remove them ..... only to now find out I've just wasted a good chunk of my life I'll never get back lol,

Thanks Graham for your reply too,

Someone should probably update the page to state rowspans don't affect screenreaders, Ah well, thanks again. –Davey2010^Talk 20:15, 22 May 2020 (UTC)

I've made it my mission as well, and annoyed a handful of editors. I wish I could find that original thread though. Walter Görlitz (talk) 03:54, 23 May 2020 (UTC)

Hi Walter Görlitz, I for once didn't annoy anyone doing this although I was linking to "WP:Manual of Style/Tables#Accessibility and WP:Accessibility which turned out to be the same page too!,

In the past I've had 2 maybe 3 discussions on it but can't for the life of me find them as they were all between 2015-2017 :(,

Just a pain to be told the wrong information, we all then put some work in to remove the problem ... and then we find out it wasn't a problem to begin with!, The joys of the Wikipedia eh the joys! :), Thanks, –Davey2010^Talk 11:00, 23 May 2020 (UTC)

I seem to recall some kind of kerfuffle about Doctor Who seasons. --Redrose64 🌹 (talk) 18:32, 23 May 2020 (UTC)

How descriptive should table captions be?

Per MOS:TABLECAPTION, all data tables should have captions leading them. Sometimes, the captions are pretty bare-bones, such as "Records by season" or "Albums", whereas I am of the opinion that they should be descriptive enough to stand on their own--i.e. "[Sports team] records by season" or "[Recording artist] albums". My thinking here is two-fold: 1.) the function of a caption is to describe the contents of the table, so unless a table is about the concept of records by season or generally about albums, it's necessary to add these caveats and 2.) sometimes, these tables are inserted into other articles--e.g. with many lists of television series episodes--so there are times when the context is not quite as obvious as when the table is included in [sports team]'s or [recording artist]'s bios. Thoughts on best practices here and any language we can use at MOS:TABLECAPTION to make the best practices clear? ―Justin (koavf)❤T☮C☺M☯ 04:33, 27 May 2020 (UTC)

Your "descriptive enough to stand on their own" flies in the face of advice at MOS:HEADING, were the article title or previous heading should not be repeated. It's assumed the reader already knows the article and so if there's a table on an article titled "Album", then that if that table is titled only "Certifications", the reader knows it is certifications for album. If it were on an different article, say for the artist, yes, then it should have a more descriptive title.

Is there a technical reason that a screen reader or its user would be confused without one? Walter Görlitz (talk) 05:09, 27 May 2020 (UTC)

Walter Görlitz, MOS:HEADING doesn't refer to table captions and table captions aren't section headings. They just serve different purposes. I do not know of a technical reason why one would be confused other than the very common example that I gave of transcluded tables that will appear elsewhere in the encyclopedia. ―Justin (koavf)❤T☮C☺M☯ 10:15, 27 May 2020 (UTC)

But that's not the point I'm trying to make, which is, we do not need to repeat information. Tables inside an article can be assumed to be content for that article, so just as HEADING states we shouldn't repeat information, I'm saying we don't need to for tables.

It's more common for tables to be stand-alone than to be transcluded. So in the cases where the latter is the case—usually when they're in a template—it makes sense to have descriptive headings, but it's a better argument not to have tables in templates. Walter Görlitz (talk) 14:29, 27 May 2020 (UTC)

I'd say shorter is better, just so it's easier to skip over a table if necessary. Graham87 16:41, 27 May 2020 (UTC)

Agree with Graham about length.

@Walter and Justin: it's also a matter of third-party re-use. One of our tables can be a single chunk of information to copy into another wiki for whatever purpose (and its caption goes with it), so it's helpful to have sufficient information to distinguish it. Although, if it is as brief as "Records by season", a third-party re-user can always augment the caption for their own purpose, so it's not a crucial factor. Best not to overthink these issues, I guess. --RexxS (talk) 21:10, 27 May 2020 (UTC)

Breaking within infobox parameters

Is there any guidance on forcing linebreaks within infobox parameters that are not lists? See for example |office6= on Nancy Pelosi, but there are many more - seems to be particularly common in uses of {{infobox officeholder}}. If this is something to be avoided I suggest it would be worthwhile to explicitly say so in this guideline. Nikkimaria (talk) 21:27, 29 May 2020 (UTC)

It's not a big deal. I've removed the ones at Nancy Pelosi as "unnecessary", but no doubt somebody will want to put them back, and I won't worry.

There are other times when two different pieces of information are put into a single field and there's certainly no problem with using a line-break to separate them visually in those sort of cases. The problem with giving guidance on these sort of issues is that there are so many different cases that it's hard to legislate for all of them. Lists are the easiest ones to spot and the place where proper markup will do the most good. I'd be tempted to leave it at that. --RexxS (talk) 22:24, 29 May 2020 (UTC)

Breaks are horible for screen readers.--Moxy 🍁 22:37, 29 May 2020 (UTC)

LISTGAP clarification

Is this discouraged under MOS:LISTGAP? That is, does it cause the problems for screen readers described there?

: I like this idea.  [[User:Example]] 
* I don't like this idea.  [[User:Example 2]] 
: I don't like this discussion.  [[User:Example 3]] 

―Mandruss ☎ 15:36, 19 May 2020 (UTC)

No, the aim is consistency. Assuming that these three are all replying to an unindented suggestion that you've not provided, they may be either

: I like this idea.  [[User:Example]]
: I don't like this idea.  [[User:Example 2]]
: I don't like this discussion.  [[User:Example 3]]

or

* I like this idea.  [[User:Example]]
* I don't like this idea.  [[User:Example 2]]
* I don't like this discussion.  [[User:Example 3]]

But if Example 2 were replying to Example, then this

: I like this idea.  [[User:Example]]
:* I don't like this idea.  [[User:Example 2]]
: I don't like this discussion.  [[User:Example 3]]

would be allowed. --Redrose64 🌹 (talk) 16:23, 19 May 2020 (UTC)

@Redrose64: I think that's what I thought. I've for years been under the impression it's all about screen readers, being part of the MOS accessibility page. I knew that bullet-commenting in an unbulleted thread makes clear threading unnecessarily difficult – to the point where clear threading is all but abandoned – but it isn't entirely clear that's discouraged by LISTGAP. I think it should be made so. ―Mandruss ☎ 17:56, 19 May 2020 (UTC)

Well, it does concern screen readers, since upon encountering each list they describe the list including the number of items. So for your original case, three lists of one item would be announced; for my first two examples, each would be announced as one list of three items; and my third example would be announced as a kist of two items, the first item also containing a list of one item. So the overall number of items is three for all of them, but the number of lists differs. We're aiming for a situation where a list isn't terminated only for another to start immediately. --Redrose64 🌹 (talk) 18:19, 19 May 2020 (UTC)

(edit conflict) @Mandruss: It's discouraged by MOS:INDENTMIX (both are discussed in the same section): "Likewise, do not switch between initial list marker types (colons, asterisks or hash signs) in one list". It is principally about screen readers and I wrote an essay on it at WP:Colons and asterisks. --RexxS (talk) 18:25, 19 May 2020 (UTC)

@RexxS: The guidance is currently unclear on that point. I guess my example above was not illustrative. In its simplest form:

I'm starting this discussion.  [[User:Example]] 
* I don't like this discussion.  [[User:Example 3]]

does not "switch between initial list marker types (colons, asterisks or hash signs)" because the opening comment had none of those three. And it's hardly clear that "list" in this context is synonymous with "thread" or "discussion". If the intent is to discourage that, it should be discouraged with more clarity, which could be accomplished with one additional example. ―Mandruss ☎ 18:42, 19 May 2020 (UTC)

@Mandruss: Your example there causes no problems, because the opening comment had none of those three. The section in MOS:ACCESS is titled Lists because threaded discussions are lists. The current wording is "For example, in a discussion, do this best practice:" which seems to me to refer to discussions, as does "When indenting in reply ...". Nevertheless if you can improve the wording, why not do it? I'd be interested to see what your additional example is. --RexxS (talk) 18:55, 19 May 2020 (UTC)

@RexxS: The following could be the last example at LISTGAP:

nor N this (use asterisk in an unbulleted thread):

I have an idea.  [[User:Example]]
* What is it? [[User:Example 2]]

―Mandruss ☎ 19:03, 19 May 2020 (UTC)

@Mandruss: No, there's nothing wrong with that example. It doesn't change the list style because the first comment is an independent paragraph and the second comment is the one that begins a list. A third comment would have to begin with * though. --RexxS (talk) 19:11, 19 May 2020 (UTC)

@RexxS: So the first replier (not the OP) sets the initial marker for the remainder of the thread? Almost always based on a personal preference for or against bulleting every comment? ―Mandruss ☎ 19:15, 19 May 2020 (UTC)

Yeah, pretty much. --Redrose64 🌹 (talk) 19:37, 19 May 2020 (UTC)

In that case, that should be clarified, perhaps by explicitly saying "The first replier (not the OP) sets the initial marker for the remainder of the thread". It certainly wasn't clear to me, and it will be unclear to many other editors. And that, as we know, results in much avoidable conflict. ―Mandruss ☎ 19:43, 19 May 2020 (UTC)

@Mandruss: No, because the original poster may start the thread with an indent like *. The first poster that uses an indent creates a list and that's what needs to be preserved. Period. --RexxS (talk) 20:32, 19 May 2020 (UTC)

Well fine, then clarify that! I didn't come here to improve my understanding, I came to clarify the guidance for the sake of the entire project. That is always my focus. And regardless of whether you, Redrose64, and any number of other highly technical editors understand these things because you are highly technical, the current guidance is unclear. Period. The common editor should not be required to look any further than LISTGAP to know what to do – not to this page's archives, and not to your essay. And any two minimally intelligent editors who have read LISTGAP (and believe in following the guidelines even if they are inconsistent with their personal preferences, for the greater good) should not disagree on what to do. ―Mandruss ☎ 20:48, 19 May 2020 (UTC)

As the person who first created the INDENTMIX shortcut (though I thank Pppery for retargeting it and RexxS for copying it to MOS: instead of WP:), I agree that adding that to the guideline would be a benefit, since it would mirror WP:RETAIN, but wouldn't solve all problems. For example, if the first reply uses a colon and everyone else follows with a bullet, it's often simply easier and less contentious to change the first reply rather than reformat the whole list. (While we're on the topic, I've always wondered why AfD has been allowed to get away with not adhering to the spirit of either LISTGAP or INDENTMIX, since the relisting notice is unindented entirely.) —⁠烏⁠Γ ^(kaw) │ 21:40, 19 May 2020 (UTC)

No-list indented discussions

What if we could have discussions that aren’t lists?

I’m imagining something like:

I think the article could benefit from more images. [[User:Joe Bloggs.]] dtstamp
{{ind1|p| No way! There are already too many scattered across multiple sections. [[User:N.A. Sayer.]] dtstamp }}
{{ind2|p| {{re|N.A. Sayer}} We could move them to a gallery. [[User:Valerie G.]] dtstamp }}

Which could render as:

<p>I think the article could benefit from more images. <a href=...>User:Joe Bloggs.</a> dtstamp</p>
<p class=mw-indent-1>No way! There are already too many scattered across multiple sections. <a href=...>User:N.A. Sayer.</a> dtstamp</p>
<p class=mw-indent-2>@<a href=...>N.A. Sayer<a>: We could move them to a gallery. <a href=...>User:Valerie G.</a> dtstamp</p>

With CSS like:

.mw-indent-1 margin-left:2em; /* or 5vw, or whatever */ 
.mw-indent-2 margin-left:4em;

[I won’t go into the HTML5 idea of comments as sequences of (article(footer))(article(footer))... elements. And bulleted or numbered responses would still be lists, I guess.]

What would it mean for screenreaders and accessibility in general if our conversations were paragraphs (or similar) rather than lists?

— Pelagic ( messages ) Z – (22:51 Mon 01, AEST) 12:51, 1 June 2020 (UTC)

P.S. Here by accident, asking because creating a level-5 indent as <dd><dd><dd><dd><dd>This is my 2¢</dd></dd></dd></dd></dd> is an abomination, in so many ways. Pelagic ( messages ) Z – (22:51 Mon 01, AEST) 12:51, 1 June 2020 (UTC)

It's an intriguing idea. Since the markdown we use is already a sufficiently difficult task for editors to grasp, this might prove more difficult for editors to grasp, but if it gains consensus, it looks workable. Walter Görlitz (talk) 15:15, 1 June 2020 (UTC)

I think that the present system is so ingrained (after nigh on twenty years) that you would have difficulty persuading people to change their habits. --Redrose64 🌹 (talk) 11:33, 2 June 2020 (UTC)

Some comments:

• The reason this probably wasn't done to begin with was because when widely-used templates were updated In The Beginning, they broke the wiki. This is more-or-less resolved since several years now, but something like this was something to worry about. (You can see this in the fact that we still subst {{unsigned}} even though there are other templates more widely used that end up on talk pages that probably shouldn't if we were still worried about this factor.)
  • Also, ":" is easy, for better or worse.
• Some comments are not single paragraphs but multiple paragraphs. Your proposal needs to use <div>, not <p> or provide for multiple paragraphs some other way.
• Coincidentally, the talk pages project is talking about what syntax should be used at phab:T230683. Consider taking a look. (I have a strong opinion about what they'd like to do, but haven't gotten around to commenting yet.)

--Izno (talk) 12:19, 2 June 2020 (UTC)

Interesting point. I can't recall what the limit is, but there is a limit to the number of templates that can be used on a page, and I suspect that a talk page is no different. Walter Görlitz (talk) 01:01, 3 June 2020 (UTC)

The last time this discussion came around, it was suggested that to retain backwards compatibility, minimise learning of new habits, and avoid limits on templates, the parser should render colons beginning a line on talk pages as indented divs, rather than as a description list. I think everybody agreed it was a good idea, then promptly forgot about it. --RexxS (talk) 01:25, 3 June 2020 (UTC)

Other languages on person names, cities, etc.

i have been adding lang template for person names, cities, college or journal titles on foreign wikis (es,de,pt etc.) am i doing right by adding template ? Vishnuvardhan leela (talk) 01:35, 15 June 2020 (UTC)

I'm generally meh about this ... honestly, I think it should only be done if you're fluent enough in the wiki's home language to justify what you're doing in that language (without the use of machine translation). Graham87 04:49, 15 June 2020 (UTC)

Accessibility idea/proposal

I have made a proposal for an accessibility feature for Wikipedia here - Wikipedia:Village pump (idea lab)/Archive 31#Colour text options - and I would love to hear the views of people involved in this project. Helper201 (talk) 00:22, 24 June 2020 (UTC)

Is the Video game reviews meeting requirements?

I was adding a caption to a table on a video game page, and realized that {{Video game reviews}} (used on 10,000+ pages) didn't have a "caption" element; in looking at it, though, I'm not sure it's meeting ACCESS requirements besides that? Example at Final Fantasy XII#Reception. It has a "header row" that acts as a caption, and then three sub-tables that have a data row as a header, then a header row for column headers (no colscopes), then data rows for the data (no rowscopes). I can add col/rowscopes to the subtables, and convert the top-level header to a caption, but I'm not sure that it works for screen readers even with that. Can anyone confirm if it does/doesn't work as currently designed? --PresN 14:55, 29 June 2020 (UTC)

No, it's not particularly accessible. The ideal structure in HTML 5 would probably be something to the effect of:

<figure>
  <figcaption>Reception</figcaption>
  <table><!-- one for each kind of data -->
    <caption>Aggregator scores</caption>
    <tr><th>Aggregator</th><th>Score</th></tr><!-- with scopes of course -->
    <tr><td><!--maybe could be a th with row scope, though I tend toward td -->Agg1</td><td>Score1</td></tr>
    <tr><td>AggN</td><td>ScoreN</td></tr>
  </table>
  <table><!-- ditto for reviews -->
    <caption>Publication scores</caption>
    ...
  </table>
  <table><!-- ditto for awards -->
    <caption>Awards</caption>
    ...
  </table>
</figure>

Since we don't yet have access to figures and figcaptions, those can be swapped out for role divs right now and fixed later.

I've taken a look at this problem previously and was sad about trying to clean up the module in general since the multi-reviews stuff is in there.

(While we're looking at this, we should add WP:TemplateStyles.) --Izno (talk) 15:16, 29 June 2020 (UTC)

"MOS:SMALL" listed at Redirects for discussion

A discussion is taking place to address the redirect MOS:SMALL. The discussion will occur at Wikipedia:Redirects for discussion/Log/2020 July 3#MOS:SMALL until a consensus is reached, and readers of this page are welcome to contribute to the discussion. –Davey2010^Talk 18:03, 3 July 2020 (UTC)

New addition to SMALLTEXT

[2][3][4]

User Koavf has decided to slow-burn-edit-war this, but I'm starting the discussion instead of following their very poor example.

It's unclear to me whether the editor seeks to allow "small" in infoboxes, etc, provided it's for "fine print". If so, they are effectively saying accessibility is unimportant for this "fine print", and I would strongly disagree. If not, the ambiguity needs to be cleared up. Either way, the sentence is so vague as to be fairly pointless; if somebody wants a piece of text smaller, they need only call it "fine print" to satisfy the guideline as written. Wikipedia content is not legal contracts. Finally, there's a WP:CREEP issue, and I don't know that hairs need to be split quite this finely. ―Mandruss ☎ 00:16, 30 June 2020 (UTC)

The intent that I saw is that he does not want it anywhere, but if the element is to be used, it should be used as the specification suggests, which is as side comments such as small print. --Izno (talk) 01:07, 30 June 2020 (UTC)

"Fine print" is messages like "By visiting this page, you agreed to abide by our terms and conditions no matter how our lawyers choose to interpret them". I don't see how we might ever use such "fine print" in an infobox. The closest that Wikipedia has to that is the messages like MediaWiki:editpage-head-copy-warn and MediaWiki:wikimedia-copyrightwarning displayed when you edit a page. They're not in an infobox, but in plain view above and below the edit box.

The problem with small text in an infobox is that the styling of the element may reduce the font size of the text below the smallest size that is acceptable for accessibility. --Redrose64 🌹 (talk) 15:26, 30 June 2020 (UTC)

I wonder if it wouldn't be worth setting <small> to 100% font size in common.css (where it is presently defined as 85%) just to emphasize that it's not to be used for things that would be small but instead as 'fine print'. --Izno (talk) 15:52, 30 June 2020 (UTC)

Izno, I think that's an excellent idea. ―Justin (koavf)❤T☮C☺M☯ 07:21, 4 July 2020 (UTC)

Taxoboxes (a subset of infoboxes) use <small> tags: The documentation for type species in manual taxoboxes ({{Taxobox}}) specifically suggests using them. Automated taxoboxes include small tags through the use of {{#invoke:Taxon authority|function}} and other modules. Before any changes are made to common.css, it would be a good idea to discuss it with a larger group of editors, notifying WikiProject Tree of Life and other interested groups. BlackcurrantTea (talk) 08:43, 6 July 2020 (UTC)

There are probably far too many misuses of <small>...</small> just to create a visual effect for any campaign of fixing the semantics to be successful. Most editors don't understand that the the 'small' tag carries a meaning for some users and re-users, and almost certainly don't care. --RexxS (talk) 12:49, 6 July 2020 (UTC)

My expected interaction after changing the size kind of goes like "my tag's not working" "it's not supposed to anymore. if you really think you need small text, use {{small}} (you probably don't need small text)". --Izno (talk) 02:58, 8 July 2020 (UTC)

Mandruss, "Fine print" is not just anything that you want to be small. The semantic issue is a real one and we shouldn't abuse HTML. ―Justin (koavf)❤T☮C☺M☯ 07:22, 4 July 2020 (UTC)

That is not a response to my concerns. ―Mandruss ☎ 08:43, 4 July 2020 (UTC)

Color contrast dispute at Docklands Light Railway rolling stock

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'm experiencing inappropriate pushback at Docklands Light Railway rolling stock. Two editors (C2A06 and user:Thryduulf) are insisting that the combination of {{DLR color}} (#00B2A9) with white text is "easier to read" than the template-chosen black. I've explained that the color contrast with white fails all four WCAG accessibility criteria, and provided a link to the color tool proving this: https://snook.ca/technical/colour_contrast/colour.html#fg=FFFFFF,bg=00B2A9 However, these editors continue to revert and ask for "discussion" . It's completely inappropriate to leave the article in a state which violates WP:COLOR. See discussion at Talk:Docklands_Light_Railway_rolling_stock#Infobox_color>— TAnthony^Talk 03:10, 22 July 2020 (UTC)

Please note that I reverted you exactly once, with an explicit call for you to discuss this so that consistency can be maintained (there are multiple articles and templates that use this colour scheme) but you just reverted without discussion. When I called you out on this, having started a discussion at WT:UKRAIL#DLR colours you haven't engaged with that, instead you've continued to edit war and double down that you are right and nothing else matters. Accessibility is important, but it is not the only consideration (and if you really cared about it, surely you would engage with people who don't understand to explain it and also seek to change all instances of inaccessibility?). Nothing gives you the right to edit war. Thryduulf (talk) 10:43, 22 July 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Strike to denote "defunct", "former" or "no longer applicable"

Such as {{Kintetsu Minami-Osaka Line}}. Should this be formally prohibited?--GZWDer (talk) 20:33, 10 August 2020 (UTC)

It doesn't just cause accessibility problems, it fails to explain what the strike-through means, even for 100% sighted people. --Redrose64 🌹 (talk) 20:48, 10 August 2020 (UTC)

<s> is defined as The s element represents contents that are no longer accurate or no longer relevant. This is a correct use of that element. --Izno (talk) 20:52, 10 August 2020 (UTC)

See [5], many usage of strikes are not to indicate objectionable text, but contents that are no longer accurate or no longer relevant.--GZWDer (talk) 23:03, 10 August 2020 (UTC)

<del> does have a different meaning. --Izno (talk) 23:41, 10 August 2020 (UTC)

Rowspans: officially discouraged or not?

I know that over the years I've seen editors in the wild removing excessive rowspans from tables (See the language column) because of concerns that screen readers have trouble presenting the content, but I don't see anything in the guidelines that looks like an official stance on this. Am I missing something? Can the community clarify this in the MOS? Thanks, Cyphoidbomb (talk) 16:25, 15 August 2020 (UTC)

@Cyphoidbomb: Check the thread #Rowspan and screen readers above for detail, but rowspans are handled quite well by modern screen readers these days. If there are multiple rowspans in several columns of a table, it can get more difficult to navigate, but it's not the same problem it was a decade ago when text-only browsers like Lynx were used as the standard for testing by the RNIB. It certainly never makes accessibility worse if you get rid of rowspans, and in complicated tables, it might even improve it, but it's no longer such a big deal that it's worth an edit-war over. I'm not sure you could write an official stance on that. Maybe a brief note about the history? --RexxS (talk) 20:56, 15 August 2020 (UTC)

OK, good to know. Thanks! Cyphoidbomb (talk) 21:06, 15 August 2020 (UTC)

Table formatting proposal at VPT

People who understand table formatting may want to look at Wikipedia:Village pump (technical)#Expanding class=wikitable to make tables accessible to blind, and to align cell text. Whatamidoing (WMF) (talk) 02:26, 20 August 2020 (UTC)

Accessible colours

I have been watching as an editor has added game results to Portland Timbers–Vancouver Whitecaps rivalry and am worried about the accessibility of the tables that have resulted. I have not run it through a checker, but would like some advice, preferably on the article's talk page. Walter Görlitz (talk) 23:37, 4 September 2020 (UTC)

Well, for one thing, that green's nasty. That page is a good example of several accessibility issues (color contrast, text size, show/hide buttons, table markup with(out) captions, headings, etc. It's a great example of the premise, "let's just get the content thrown on the page so it looks good for some editors on some devices, and not worry about data semantics or references too much".

More input over there would be good. — JohnFromPinckney (talk) 04:48, 5 September 2020 (UTC)

Audio & video timestamps

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/Captions#Video timestamps. Involves how to specify times in A/V material: "4:31", "4 min 31 sec", "4 m. 31 s.", etc., etc.  — SMcCandlish ☏ ¢ 😼  12:20, 26 October 2020 (UTC)

Some threads of relevance

FYI

 – Pointer to relevant discussion elsewhere.

Please see:

• Wikipedia talk:Manual of Style#Strikeout text in article
• Wikipedia talk:Manual of Style#Fixing the accidental return of decorative quotations

 — SMcCandlish ☏ ¢ 😼  05:35, 17 November 2020 (UTC)

Alt text for tick

On Template talk:Tick#Alt text we are discussing the most appropriate alt text for the check mark. Any comments would be welcome over there. — Martin (MSGJ · talk) 20:08, 18 November 2020 (UTC)

Relevant RM

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:WikiProject Disability/Style guide#Requested move 20 November 2020
 — SMcCandlish ☏ ¢ 😼  20:51, 28 November 2020 (UTC)

Feedback

Hi editors, I was directed to this page in my peer review. It is for a band, and it was brought up that the timeline for band members was not accessible as it relied only on colour to show information. I have added a letter code here to the timeline for better accessibility, but I was wondering if someone might have any further feedback about how to make the timeline better? Typically band timelines have just been published with just a colour code. Thanks in advance. SatDis (talk) 08:10, 5 December 2020 (UTC)

@SatDis: All timelines made with the timeline tag are completely inaccessible for screen reader users. The textual list above the timeline is good enough. Graham87 14:17, 5 December 2020 (UTC)

@Graham87: Thankyou for the reply. Would you recommend removing the timeline, or keeping it, without the letter code? Thanks. SatDis (talk) 14:58, 5 December 2020 (UTC)

@SatDis: The latter would be fine. Graham87 17:18, 5 December 2020 (UTC)

Thanks, Graham87! Best regards, SandyGeorgia (Talk) 19:48, 5 December 2020 (UTC)

Screen readers are improving

Some of the advice about screen readers seems to be out of date and not literally correct. For example,

Do not use unpronounceable symbols such as ♥ (a heart symbol)

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

Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" cannot be reproduced into useful text by a screen reader and will usually be read as a question mark.

I just tried these in Apple’s VoiceOver (I am not a regular user). It reads them as “red heart suit,” “dagger” (while the recommended {{†}} says “dagger image”), and “right arrow.”

I will adjust the corresponding text to say “often unpronounceable” and “might not.” —Michael Z. 16:37, 11 December 2020 (UTC)

Did this. —Michael Z. 16:44, 11 December 2020 (UTC)

@Mzajac: I think you'll find that {{†|alt=whatever you want}} gives †, which says "whatever you want". Being able to specify what the dagger indicates is a considerable advantage over the symbol.

The advice originated around 2010. Graham87 stated in this thread "It's not a good idea. I can't read the hearts symbol with JAWS." Now, it is true that screen readers have improved over the past ten years, but the most popular reader, JAWS, costs around $1,000 and many users may still be running older versions, so unless you're sure that the vast majority of screen readers used on Wikipedia can read those symbols (which I doubt you can claim), we ought to stick with unequivocal advice. --RexxS (talk) 17:45, 11 December 2020 (UTC)

I am not claiming they can. I am moderating the false claim that none of them can. If our advice doesn’t reflect reality then editors won’t trust it. —Michael Z. 18:04, 11 December 2020 (UTC)

Not all screen readers behave the same way, and I know that when someone has laid-out a load of cash, they're not quick to upgrade. We should be attempting to cater to the least capable screen reader until it because increasingly difficult to do so rather than assume everyone has the latest and best software. Walter Görlitz (talk) 18:25, 11 December 2020 (UTC)

(edit conflict) @Mzajac: And if we give advice that it might be okay not to follow the advice, then editors won't follow it, and we will never make improvements in accessibility. As far as we know, using non-ascii characters causes problems for most screen reader users. What's the outcome you're looking for? --RexxS (talk) 18:29, 11 December 2020 (UTC)

Please don’t bother schooling me. I am aware of the facts and I am for accessibility. We can’t cater to any screen reader if we don’t have regular screen-reader users advising us, so we need to adhere to accessibility principles. And we shouldn’t be blinkered thinking that “accessibility” = “screen readers” and nothing else either; it’s for re-use of data, other assistive technologies, mobile, voice, etcetera. The guidelines should accurately reflect that we should adhere to principles because the application of our text is unpredictable, and that includes that there is no single profile for screen-reader capabilities, and never will be.

I am not changing the advice. My edits did not change any advice. I am removing false assumptions. —Michael Z. 19:12, 11 December 2020 (UTC)

Please observe WP:LISTGAP and get off your high-horse. I've spent the last decade working with screen reader users like Graham87 to understand their actual experience, so I don't need your uninformed anecdotes. Did you check with "regular screen-reader users" before changing guidelines that were developed in consultation with at least one of them?

Your edits diluted the advice for no gain whatsoever. If you wanted to add a side-note that some screen readers are capable of pronouncing some non-ascii symbols, fine. But that's not what you did. --RexxS (talk) 19:44, 11 December 2020 (UTC)

I didn’t think I changed the advice to editors at all. I just want the descriptions to be factually correct. Sorry I annoyed you. I’ve reverted my edits so let’s discuss how it can be improved. Thanks. —Michael Z. 20:52, 11 December 2020 (UTC)

How about if we got away from the issue of pronouncibility altogether in the Wikipedia:Manual of Style/Accessibility #Text section? Something like "Do not use non-ascii symbols such as ♥ (a heart symbol); use images with alt text instead" (referenced to the latest WCAG guidance at https://www.w3.org/WAI/WCAG21/Techniques/failures/F26.html) would avoid giving the false impression that no screen reader can pronounce whichever character we choose as an example.

For the Wikipedia:Manual of Style/Accessibility #Link section, do you think we could soften your change to something like "Do not use Unicode characters as icons; use an image of the icon with alt text instead. Although some screen readers may be able to accurately voice a character like "→", others may read it as a question mark, and there is no comprehensive guide to which characters are acceptable."

Please suggest alternatives that may be better. Thanks for your patience; getting advice right can be very hard work at times. --RexxS (talk) 22:21, 11 December 2020 (UTC)

I wouldn’t say “non-ascii,” since other parts of the guideline refer to the potentially problematic range as “Unicode” characters, specified as outside the basic code pages: “screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252.” Example point 2. also defines the problem as “unpronounceable” symbols, which is not exactly the same; and I think earlier I may have misinterpreted that too.

I think the heart and dagger points are referring to the same problem and solution, but the latter is adding that an existing template may make it easier to implement for certain symbols. Your proposal is changing the sense a bit. —Michael Z. 00:27, 12 December 2020 (UTC)

I don't think the two sections are aimed at quite the same editors. The Text section refers to F.26 "graphical symbols" which WCAG defines as "an image, an image of text or a pictorial or decorative character symbol (glyph) which imparts information nonverbally" (which is why I considered it was referring to non-ascii characters) and it recommends that "an image with a text alternative can be used instead of the glyph." In my experience, the issue tends to be found in tables or lists where a compact marker is used either to represent a longer piece of text (♥ = "hearts suit"), or designate something († = "Captain").

The Link section seems to have been written with the express purpose of discouraging the use of Unicode characters as links. The underlying reason is, of course, the same, but the focus is on a different class of symbols. Although not all characters that cause issues with screen readers are Unicode, there is a temptation for editors to mimic other websites and applications that create compact links by using Unicode characters, and I think that was the target audience for the specific point. --RexxS (talk) 01:22, 12 December 2020 (UTC)

Mzajac helped me with accessibility issues when I had my first major accessibility problems with the site way back in 2006. As for the Unicode section, I was thinking recently that it needed an update but didn't really know where to start. I like the recent changes and put them back briefly before wondering if that'd make things more complicated.

@RexxS:, you might recall this discussion on your talk page re how card suits are read out by various screen readers. NVDA is a free screen reader that's a viable alternative to JAWS these days for quite a few people (but certainly not all) and it's got reasonable Unicode support now in its default configuration. Also, as its article says, it was more popular than JAWS in the latest survey of these things. I've therefore removed the explicit reference to JAWS from the guideline and updated that section a bit. Graham87 05:48, 12 December 2020 (UTC)

Thank you, Graham, I'm more than happy to defer to your experience. Cheers --RexxS (talk) 22:19, 12 December 2020 (UTC)

Wow, what a memory. Thanks. —Michael Z. 00:39, 13 December 2020 (UTC)

I use NVDA and genearly it's not a problem for these symbols. What is a problem is white spaces and break codes.....as many times to move forward past these spaces it has to be done manually.--Moxy 🍁 03:39, 13 December 2020 (UTC)

I've put the new changes back and made some further tweaks. Graham87 03:53, 13 December 2020 (UTC)

Looks good. —Michael Z. 17:59, 13 December 2020 (UTC)

Template:Tooltip, Template:Hover_title, and Template:Abbr

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Templates for discussion/Log/2020 December 3#Template:Hover title and Template:Tooltip

Summary:

• {{Abbr}} (a wrapper for <abbr>...</abbr>) has long been abused for non-abbreviation markup (against the HTML specs).
• We had a template, {{Tooltip}}, with <span>...</span> for non-abbreviation use, but it was "merged" (not really) and redirected to {{Abbr}}.
• The redir was then deprecated (for the reason mentioned above), but the community ignored the deprecation.
• In the interim, {{Hover title}} was created to do the same thing, but with backwards parameters (and some additional features).
• Both the {{Tooltip}} then-redirect and {{Hover title}} template have been transcluded in tens of thousands of articles, mainly via infoboxes and other templates.
• I created a new {{Tooltip}} template, with all the features of {{Hover title}} but preserving the {{Abbr}} parameter order (to not break deployed translcusions).
• The TfM linked above would merge away {{Hover title}}, but it's going to require flipping the |1= and |2= parameters of its extant instances.
• Oh, and the documentation would need updating after merger, of course.

I'm mentioning this here at WT:MOSACCESS because a few years ago, accessibility concerns (I think in regard to particular user agents) were raised about this entire class of template/element/attribute. While this TfM will not do anything about that, it might change the loci of the issue(s); and they probably need re-examination anyway, since so much time as passed.  — SMcCandlish ☏ ¢ 😼  00:29, 4 December 2020 (UTC)

 — SMcCandlish ☏ ¢ 😼  00:29, 4 December 2020 (UTC)

• Instead of recreating templates that the community decided should be exist, you should read MOS:NOTOOLTIPS. --Gonnym (talk) 13:14, 5 December 2020 (UTC)
  • Instead of rule-thumping at me, about things that are probably the most moving-target that MoS ever attempts to address, try being part of the solution?  — SMcCandlish ☏ ¢ 😼  10:00, 14 December 2020 (UTC)

See #New tooltip testcases, below.  — SMcCandlish ☏ ¢ 😼  10:12, 14 December 2020 (UTC)

New tooltip testcases

Users of screen-readers, I've set up some new tests at Template:Tooltip/testcases, to see about having Template:Sronly provide a workaround for title= tooltips to make them accessible. If this works as well in practice as it does in testing so far, this is probably the way out of the problem of tooltips being used and being inaccessible, but the community by and large just ignoring the accessibility issues and doing it anyway. It's better to just fix the problem technologically than to try to continue arm-twisting editors (who mostly don't read guidelines anyway) into doing something they don't want to.

If this does work well, then Wikipedia:Templates for discussion/Log/2020 December 11#Template:Hover title and Template:Tooltip is still ongoing. This is a merge proposal of some tooltip templates (that do not abuse the <abbr>...</abbr> element), but before the above mentioned {{sronly}} work were objected to as MOS:TOOLTIP problems. And, if this does work well, that guideline section will need updating, as will various templates that have for years used tooltips despite what the guideline section has been saying.  — SMcCandlish ☏ ¢ 😼  10:12, 14 December 2020 (UTC)

"This guideline doesn't apply outside of mainspace" (and variants)

I have had multiple editors utter those words in recent weeks. I think it was a mistake to move this under the MOS page way back when (24 May 2010). Multiple parts of it are expected to be followed outside of main space. Most especially LISTGAP of course (talk pages are a PITA), but there are other parts that are just good sense.

Would anyone find it palatable to move this back out to WP:Accessibility? --Izno (talk) 05:41, 6 December 2020 (UTC)

I don't think that moving the page would help—it doesn't matter where it is, the question would still remain as to whether its advice applied at a particular page. Why not take the guidance of WP:Signatures which declares that it is a guideline, but certain marked sections are policies? The accessibility page probably doesn't need quite that, but it could spell out exactly where the advice applies. Johnuniq (talk) 06:59, 6 December 2020 (UTC)

I'd move it in an instant if that would guarantee a solution. The problem at present is the opening sentence of Wikipedia:Manual of Style, which encourages editors to think that accessibility guidelines don't apply outside of articles. I've added a rider "However, accessibility guidelines apply across the entire project." and we'll have the fight here when some pedant decides to revert it because "it doesn't have consensus". --RexxS (talk) 01:30, 7 December 2020 (UTC)

• Move it back. Accessibility issues go to the core purposes of Wikipedia, and increasingly accessibility is a legal issue. It is not just a style issue. Style is subject to accessibility issues, not vice versa. The MOS have a tendency to overreach, and MOS is just a guideline, and it is commonly appropriate to push back against MOS warriors, and so, important things, like accessibility, should not be subpaged to the WP:MOS, but should be their own top level policy pages. --SmokeyJoe (talk) 01:39, 7 December 2020 (UTC)

WP:PRJC.--Moxy 🍁 03:47, 7 December 2020 (UTC)

... And? --Izno (talk) 13:20, 7 December 2020 (UTC)

Establish wording we could already use.--Moxy 🍁 16:54, 7 December 2020 (UTC)

It's a start, but only establishes accessibility as applying to WP: space. Welcome as that is, we still ought to have a clear documentation of the fact that accessibility guidelines must apply elsewhere as well. It should be obvious that all talk pages fall within its remit, as well as template and module documentation, and any other prose-containing page that needs to be read by a user. --RexxS (talk) 18:49, 7 December 2020 (UTC)

No, don't move it. Just add a note in its lead that it applies outside of mainspace. Where pages are matters less than what they say. If there's any kind of doubt, just go to WP:VPPOL and open an RfC on whether what MOS:ACCESS says applies to other namespaces, and the answer of course will be "yes".  — SMcCandlish ☏ ¢ 😼  10:15, 14 December 2020 (UTC)

Apparently the NASCAR Manual of Style ignores accessibility

NASCARfan0548 (talk · contribs) has been reverting changes to articles about NASCAR driver articles that I stumbled across recently. They ignore MOS:SMALLTEXT creating tables that have a font size less than 75% of baseline, and then they make some text in the table small! This is an example and this is another. NASCARfan0548 claims there is a manual of style, but has yet to point to it, so I'll open the discussion here. Walter Görlitz (talk) 16:21, 11 September 2020 (UTC)

• Found Wikipedia:WikiProject NASCAR/Standards which says nothing about size and Wikipedia:WikiProject NASCAR/quickbio which has a table example with size 80%. Both are not guidelines and regardless it really doesn't matter if they were. NASCARfan0548, just follow the actual MOS:SMALLTEXT guideline. --Gonnym (talk) 16:47, 11 September 2020 (UTC)

  Gonnym, Why? Most results tables have a 75% font size, just look at Jimmie Johnson, Kevin Harvick, and Kyle Busch's results tables, for example. NASCARfan0548 ↗ 18:06, 11 September 2020 (UTC)

  Have you read the guideline linked above? The answer is there. The fact that other pages are doing something wrong, is reason to fix them, not continue with it. --Gonnym (talk) 18:50, 11 September 2020 (UTC)

For what it's worth, small text for finishing results is commonplace across all motorsports disciplines (Formula One, IndyCar, among others use it; WP:F1 also has an example table). I can't speak too much on the NASCAR table width as I believe that was set before my time, but when you consider how long a NASCAR season is (36 races for Cup, and the Grand National Series had as many as 62 at one point; F1 and IndyCar usually do not exceed 25)...

In any case, since this likely has ramifications that affects the other projects too, I have brought this up at WikiProject Motorsport in case anyone else wants to chime in. Zappa⚡Matic 20:55, 11 September 2020 (UTC)

It will be useful for projects which are unaware of MOS:FONTSIZE to understand that there is a minimum accepted font size laid out as a "bright line":

Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that <small>...</small> tags, and templates such as {{small}} and {{smaller}}, should not be applied to already-reduced text within those elements. Under no circumstances should the resulting font size of any text drop below 85% of the page's default font size (i.e. 11.9 px in Vector skin or 10.8 px in Monobook).

This restriction on the minimum font size that is acceptable in Wikipedia articles for reasons of accessibility is not negotiable, and I am wiling to sanction editors who breach the guideline without good reason once they have been made aware of MOS:FONTSIZE. --RexxS (talk) 13:57, 12 September 2020 (UTC)

Is there a good reason that the tables in those articles linked above are horizontal (other than that, they already exist that way)? If they were vertical, with the years running horizontally, and the 30-some events running down the page, it'd be easier to use larger (you know, legible) text in the zillionty individual cells. FWIW. — JohnFromPinckney (talk) 19:45, 12 September 2020 (UTC)

It's much more common to read a row horizontal than vertical. It's also much harder to create the same table with rows vertical (the items that come one after another, don't belong to each other). Also, I'm not quite sure how accessibility programs know how to read them as vertical rows instead of horizontal ones. --Gonnym (talk) 14:12, 15 September 2020 (UTC)

I don't know that it is harder to create vertically.

In this case it's not about screen readers, it is about those who cannot read the content when it becomes too small, but that's a good point. Walter Görlitz (talk) 17:10, 15 September 2020 (UTC)

Well, the screen readers would read the info as presented the same way humans would figure it out. In that case, the table would be a list of events in the year, for each year (instead of, as they now are, a list of years, which have some events). So the table would list the 1st event, the 2nd event, the 3rd, etc., of the first year, then the 1st event, the 2nd event, the 3rd, etc., of the second year, and so on, with the results of that-numberth event for each columnar year shown at the intersecting cell.

Like Walter, I don't see the increased difficulty, except that it'd be a little different from other tables. One would have to think about what one was doing. — JohnFromPinckney (talk) 17:55, 15 September 2020 (UTC)

(edit conflict) @Gonnym: all modern screen readers are capable of switching to "table mode", where the user can simply read down a column. There's a typical description at HTML Tables with JAWS, which I highly recommend for anyone trying to get to grips with how screen readers work, and the effect of our editing decisions on visitors trying to make use of that functionality. Cheers --RexxS (talk) 17:57, 15 September 2020 (UTC)

Has anyone worked with this project to get them to line-up with font sizing? Walter Görlitz (talk) 02:29, 17 December 2020 (UTC)

Regarding horizonal vs vertical and the number of overall cells, I only edit team sports, where we don't break down an individual's stats on a per-game basis, or itemize each opponent for each season. We summaraize the season, and die-hard fans can always go to external stat sites with more detailed info. Do non-team sports or motorsports need to be different? At a minimum, those tables going off the screen is even worse on mobile devices.—Bagumba (talk) 06:11, 17 December 2020 (UTC)

Group of users interested in changes to CSS

I don't really have a good idea where to go for this one: a group of users interested in CSS changes on the site. Since Edokter left, it's not really obvious to me who has CSS knowledge and will weigh in on questions of whether a CSS change/use is a good one (opinionated people are sometimes useful ;).

For example, here's some things to think about:

1. I have some 4-5 TFDs that could use a little advertisement. Wikipedia:Templates for discussion/Log/2020 December 20#Template:Columns is one that has direct bearing on this page, while a set of TFDs presently on Wikipedia:Templates for discussion/Log/2020 December 15 (likely to be relisted again without feedback) concerns several templates that are providing inline styles that... really aren't needed anymore.
2. Lastly, I'm wondering where to go concerning some templates like those in the December 15 listings that have vendor-prefixes but we're serving 95% of our traffic (possibly more; going off caniuse.com) to users that don't need the prefixes (the ones in mind are Template:Column-width and Template:Column-count off the cuff). What should be our threshold for using/not using vendor prefixes? (A note for one of the advertised groups, WP:TemplateStyles does not support vendor prefixes, for better or worse; I find it hard to countenance support when these styles are basically guaranteed not to be supported/necessary after a certain date and in most cases vendor prefixes are not needed for sufficient if not beautiful display these days.)

--Izno (talk) 22:04, 20 December 2020 (UTC)

EDokter left because certain people marched in and, by attempting to destroy their credibility, severely annoyed them (BTW, this has recently happened to me). Apropos of the actual issue here, I have some CSS knowledge (but I'll probably be ignored or discredited too). --Redrose64 🌹 (talk) 22:16, 20 December 2020 (UTC)

I take no opinion on the matter of him leaving, I just know he was the most visible. ;) I mostly interested on whether there should be a WP:WikiProject CSS or if an existing talk page suffices (whether that's one of the ones I notified about this thread or otherwise). --Izno (talk) 23:16, 20 December 2020 (UTC)

We can consider what the Wikimedia Foundation supports: it provides a "modern experience (Grade A)" when brower usage is over 5%, and "[b]asic support (Grade C)" for anything over 0.1% in the last 12 months. Grade A means that capabilities provided by modern browsers are used, with a "graceful fallback for older browsers".

Given that based on their nature, vendor-specific prefixes should only be used in a manner that degrades gracefully, personally I think they are good candidates to phase out more rapidly once the corresponding W3C property is well-supported. isaacl (talk) 22:27, 20 December 2020 (UTC)

I have considered the support matrix. For example, with Template:Column-width, we still serve browsers in grade C that would benefit from the vendor prefixes. Does that mean we should? Clearly column width devolves gracefully since we did not support IE < 10 all those years. Is it reasonable now not to support a similar set of users using ancient browsers? --Izno (talk) 23:16, 20 December 2020 (UTC)

One of our principles is making content available to as many people as possible, and that might mean supporting older browsers for longer. My experience over the years is that many readers don't necessarily have any control over the version of the browser they are using. Folks browsing from libraries, educational institutions, companies, etc. often have their software locked down by IT departments that want to do the minimum amount of updating possible, and The IT Crowd is embarrassingly accurate. Now, things may be improving since I stopped having to deal with that, as browsers might be allowed to update themselves automatically, but I still worry that a not-insignificant fraction of our readership is unable to update from the ancient browsers that they use. When we have many articles whose page views exceed one million per year, even 0.1% is a lot of folks who may not be getting much support from us.

I suppose we'd have to do the research, but I'd guess that hanging on to vendor prefixes is one of the cheapest fixes we could make for some users. --RexxS (talk) 01:17, 21 December 2020 (UTC)

I think each proposed removal of a vendor-specific property should be examined to see how it degrades. But if they were introduced appropriately initially, the design should have already degraded gracefully, since by definition only a limited set of browsers supported them. So where the behaviour of the standard property matches that of the vendor-specific property, I think a quicker phase out can be reasonable. If there was a change in behaviour, then it depends on how much of an effect the change has. isaacl (talk) 02:18, 21 December 2020 (UTC)

Do we know what are the browser usage stats for English Wikipedia? Based on caniuse.com's page for the column-width property, IE 6-9 is at 0.36% global usage, Firefox <50 also at 0.36%, Chrome <50 at 0.56%, Safari <9 at 0.2%, iOS Safari at 0.12%, and Samsung Internet 4 at 0.28%. If we're using 0.1% as a threshold for multi-column support, then we can continue to support them. I don't think there is any differences between the vendor-specific property and the standard one. On the other hand, for this specific template, there probably isn't a lot of upside to removing the vendor-specific property (client-side processing would speed up very slightly), as the CSS is simple and I don't think it will interact with anything else in an unexpected way. So I'd probably lean towards keeping it for now. isaacl (talk) 02:37, 21 December 2020 (UTC)

Long comment ahead; TLDR: we can get rid of these IMO.

Yes, we do have data, but not trivially integrated (unlike caniuse). For context, we do not serve the following browsers per phab:T266866: Firefox < 27, Chrome < 31, Safari < 9, Opera < 18, Android < 5, and either IE < 9 is not served or is directly not supported as grade C per the matrix. Anyway, some numbers for the versions we do serve:

1. Samsung Internet 4.X irrelevant per TLS support. (We also don't see traffic < 11.)
2. IE < 10 irrelevant as IE < 10 doesn't support columns and IE > 10 is unprefixed.
3. Firefox 38 is < 0.1% of all Firefox browsers which is 4.6%. We serve no other versions < 50. That's 0.0046%.
4. Chrome for Mobile 38: 2.3% of 26%, which is 0.598%. No other versions of Chrome < 50.
5. Chrome 34 and 49 cumulatively 0.32% of 24% = 0.0768%. No other versions of Chrome < 50.
6. Safari < 9 irrelevant per TLS support.
7. Opera has no traffic below the threshold (in fact, it's all > 70).
8. There's some 10% of an unknown Other, but I assume WMF Analytics knows enough about that 10% to say it's not one of the others of interest. (It is explicitly not the set of browsers unsupported by TLS; WMF is still seeing non-0 traffic for Firefox 3 even though we don't serve it and tracking it as Firefox accordingly.)

Total of those served by WMF is ~0.68% of all traffic we know about. Removing the mobile Chrome is instead 0.08% for all browsers we know about.

Columns support degrades gracefully to a single column where unsupported (that's why we've been using it even though IE < 10 never supported it) and in mobile it is unrealistic to expect more than 1 column. You might get 2 if you're on an exceptional device on mobile (or using column-count; more on that below), but such users I would expect to keep up on their version of Chrome (I use Firefox for Mobile, as it happens). In total, I do not think we should care about mobile for columns support. (I suppose the numbers above for these threshold are useful for other analysis since we're looking at it, for ease of reference later for some reason or another.) Given all that, I think I will be:

1. Advising use of the standard column properties only, where a page is not using the template;
2. Modifying Template:Column-width and friends to output only the standard version of the CSS (column-rule and column-gap have slightly different support characteristics but nothing of interest when I looked that changes the above numbers);
3. Nominating these templates for TFD, inline with the current nominations related to borders and gradients.

Particularly for Template:Column-count prior to TFD, I think we should look into making it act like Template:Reflist does today, with absolute column counts converted (probably) to the Template:Reflist column widths, automatically. (At least in mainspace; users can do what they want elsewhere.)

That all said, that's particular to columns support. :) I'm more interested in some rules of thumb we can use. This comment took me an hour or two to put together, and I'd like not to dig through Dashiki more than once every while if I can. (Perhaps to update some particular version numbers providing guidance somewhere onwiki on what CSS we can/should employ onwiki with/without heavy CSS fallbacks.) --Izno (talk) 06:47, 21 December 2020 (UTC)

I suppose smaller column widths than our general 30em, as I encountered at Template:Signpost-main-page-body-begin, might be interesting for that analysis related to mobile, but I'm still sitting here non-plussed on the point, since mobile users should also generally be used to single column displays for most things. We're still saving some 20-60 characters (uncompressed) for each download for each use (and probably topping out at 20 after compression). --Izno (talk) 07:07, 21 December 2020 (UTC)

Well if we have the data on per version use available now, hopefully you don't have to regenerate the stats every time. Sounds like you've decided on what you want to do already. Like I said, my guidance would be to examine the benefit from elimination. I am aware, though, that my comfort level with CSS syntax puts me out of synch with editors who prefer template syntax, so I might weigh the benefits differently. Moving forward, perhaps we ought to avoid vendor-specific prefixes to avoid issues with their implementation varying from the standard property when it is specified, and thus simplify future maintenance. isaacl (talk) 15:10, 21 December 2020 (UTC)

I've watched MediaWiki:Common.css for ... a very long time ... because I care and know it's there, and feel that anyone who cares about the site CSS and has been around a while is, or at least should be, doing the same. Newer and less technically minded users may not, and would likely end up at the Village Pump if they had a site layout/styling suggestion or complaint, which may end up being concluded as CSS related even if it didn't start that way. The somewhat temporary nature of VP threads (I know we have histories and archives, but we've probably all "enjoyed" searching them for that thing you remember from years ago "now when was it?") makes them less than ideal for tracking and managing the progress of a very narrow bandwidth issue like the site CSS, so I'm with Izno with the suggestion of a WikiProject or similar where the boffins and newbies can collide ... I mean collaborate. Threads started on the commons talk page can be brought to the attention of the project, and threads started at the VP can similarly. Seems reasonable. vendor prefixes etc. *grumble grumble* Fred Gandt · talk · contribs 01:44, 21 December 2020 (UTC)

For template-related CSS questions, perhaps Wikipedia talk:WikiProject Templates would be a good place for discussion (though the term CSS hasn't been used since 2018)? For site-wide CSS questions, Wikipedia:Village pump (technical) might be good. isaacl (talk) 03:36, 21 December 2020 (UTC)

The loose rules we traditionally use in core are:

• Grade A is fully supported
• Grade C is not actively tested, but has limited support. It should be readable but might not always be pretty (ie. it should degrade to a single column, instead of having potentially broken columns). If we find big CSS problems we fix them (I remember we once fixed a problem with CSS causing blank pages in Safari 5 for all pages).
• older than Grade C is not supported and should not be expected to render correctly.
• Text only (without any CSS) should always work (because machine readability)
• We tend to actively remove vendor prefixes and browser hacks for browsers that can't realistically receive our html any longer.
• We tend not to bother removing vendor prefix statements for browsers younger than that (the Grade C class) to avoid breaking something that works, unless we do a big rewrite of something.

Use as desired. —TheDJ (talk • contribs) 20:51, 22 December 2020 (UTC)

To clarify one more point. One of the risks of vendor prefixes is that their actual effect can be different from the non-prefixed versions, or that you are combining multiple prefixed statements while only one or more of those statements works in older browsers and thus gives you an unexpected and broken result in very specific browser versions, that you will never be able to test against yourself. As such, when most modern browsers support the unprefixed logic, it is often easier to write one fallback scenario for all older browsers with simple predictable non-prefixed 'old' features and only use the unprefixed version of the 'new' feature to enhance your visuals in modern browsers. Then you only have to deal with 2 scenarios: supports 'new' feature, does not support 'new' feature and everything becomes much more predictable. —TheDJ (talk • contribs) 21:02, 22 December 2020 (UTC)

I've also taken a short look at the TfD's mentioned. I find it a typical example of the problem of technical work within the English Wikipedia community. "We don't know, so lets not encourage change because it might break something". The precautionary principle works very badly if only very few users have enough background to participate. It demotivates those who DO want to work on this and causes eternally stale technical status quo. This is why i generally just change things that I know should be changed. Its better to ask forgiveness, and all that. Once templates are not in use, they are easy to delete ;) —TheDJ (talk • contribs) 21:22, 22 December 2020 (UTC)

Templates that get orphaned out of process get people looking at you strange. ;) That aside, my thread here spurred some people to go comment over there, so I'll take whatever I can get. As I said above, one of the reasons I opened this thread was to see if we need or want thresholds so we can make it obvious for people what is/is not safe to use when writing CSS on wiki (or where unsafe, safe backups that can be written). It's useful to have the core view of things I guess as a point of interest. --Izno (talk) 22:08, 22 December 2020 (UTC)

I agree that some matters are best discussed amongst those who know the necessary background (or are willing to learn enough context), but for better or worse, English Wikipedia discussion tradition generally gives each person's opinion roughly equal weight. There are advantages to this, but it makes it harder to make decisions where specialized knowledge is needed. isaacl (talk) 02:34, 23 December 2020 (UTC)

• I've been trying to make WT:WikiProject Usability the go-to place to discuss changes to the site's appearance (which overlaps a bunch with CSS). It's not fully relaunched yet, so the talk page is mostly me, but I'd suggest watchlisting it if you're interested. {{u|Sdkb}} ^talk 23:20, 22 December 2020 (UTC)
• In brief: I like TheDJ's rubric; I agree with Isaacl's observation on wiki consensus process not working as well as it should in highly technical areas, though I'm not sure what the fix is; and I agree with Sdkb that repurposing an existing wikiproject is better than starting a redundant new one.  — SMcCandlish ☏ ¢ 😼  21:11, 31 December 2020 (UTC)

Rather than post it in the middle of all that, TFDs submitted for the column templates at Wikipedia:Templates for discussion/Log/2021 January 8. --Izno (talk) 06:28, 8 January 2021 (UTC)

WP:COLLAPSE being ignored

2020_coronavirus_pandemic_in_Ontario has a section that renders as just headings with Javascript disabled. Likely due to violation of WP:COLLAPSE. As that page is semi-protected I can't fix it myself, and an edit request on its own talk page has had no effect. — Preceding unsigned comment added by 70.52.178.195 (talk) 23:46, 17 January 2021 (UTC)

The section COVID-19 pandemic in Ontario #Statistics has all of its content made using the {{Graph:}} extension, documented at mw:Extension:Graph. Unfortunately, with JavaScript switched off, the extension does not render anything. The guidance at mw:Extension:Graph #User defined fallback suggests using an image to be displayed if there is no client-side JavaScript, but I don't suppose anybody will want to generate 10 fresh images and upload them every day after already putting all the work into providing the graph version. --RexxS (talk) 00:38, 18 January 2021 (UTC)

This seems like a case where alt text should be provided. Unfortunately, I don't think that there is provision for it in the graph extension. --Redrose64 🌹 (talk) 11:09, 18 January 2021 (UTC)

Usually, we add html to be rendered when Javascript is disabled like this:

<script>/* Javascript goes here */<noscript>Shows when Javascript is off</noscript></script>

Unfortunately the parser will not allow us to write Javascript in-line (for good reason!), so this sort of syntax isn't supported. We're left with the image fallback mechanism described at mw:Extension:Graph #User defined fallback (using the fallback="filename" attribute on the <graph> tag) until a new service is implemented. --RexxS (talk) 19:03, 18 January 2021 (UTC)

The section in question was rendering correctly, without JS, until about a week ago. This should be a simple matter of reverting something, in other words. In the meantime it's an accessibility violation, withholding part of the article content from users of some devices. — Preceding unsigned comment added by 70.52.178.195 (talk) 20:47, 18 January 2021 (UTC)

No, the Graph extension is being deliberately moved to client side in its entirety. It is only accesisbility violating if we have no other fallback content in the article e.g. a table, or an image directly for the graph. Most of the covid articles have that. --Izno (talk) 23:54, 18 January 2021 (UTC)

According to Wikipedia:Manual_of_Style/Accessibility#Users_with_limited_CSS_or_JavaScript_support "features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used." I don't want to hear any more excuses. I want that article fixed. There is no legitimate reason for witholding information about an ACTIVE PANDEMIC from a subset of people, and there is not, AFAIK, any other place aggregating some of this information (e.g. active case counts vs. time) that doesn't require client-side scripting to be enabled (not possible for some users, and a significant security risk for the rest).

Wikipedia is supposed to be readable without Javascript. Period. — Preceding unsigned comment added by 70.52.178.195 (talk) 00:47, 20 January 2021 (UTC)

You want Wikipedia fixed to your specification: you fix it yourself. Everybody here is a volunteer, and few of us are motivated by demands. --RexxS (talk) 02:00, 20 January 2021 (UTC)

Yes, the correct thing to do is to fix the issue by adding a separate table or a backup image. Moving to client-side JavaScript is not something we can change (for various reasons; see phab:T242855 and phab:T211881). --Izno (talk) 19:35, 20 January 2021 (UTC)

No, I want Wikipedia fixed to the specifications laid out in Wikipedia:Manual_of_Style/Accessibility#Users_with_limited_CSS_or_JavaScript_support ... there is a difference. And I can't fix it myself. As previously mentioned, the article at issue is semi-protected. — Preceding unsigned comment added by 70.52.178.195 (talk) 02:30, 21 January 2021 (UTC)

You may file a {{edit semi-protected}} request with your proposed wikitext on the talk page and someone will attend to it.

I want Wikipedia fixed to the specifications This will not happen on any timeline you can affect besides the method already provided (to wit, fix it yourself) unless you are willing to correct the code per the Phabricator tasks identified above. Period and end of story. --Izno (talk) 04:27, 21 January 2021 (UTC)

And I want you to start signing your posts (e.g., with four tildes ~~~~), but that doesn't seem to be happening either. — JohnFromPinckney (talk) 12:14, 21 January 2021 (UTC)

I told you. It's semi-protected. I CAN'T FIX IT MYSELF. I also lack the expertise with the code being used. And what is with all the nagging about signing things? The computer does it automatically after a short time anyway so I don't see that it's worth the effort. Besides, if everything was working correctly around here there would be nothing to sign, because the Ontario COVID page would be perfectly readable without Javascript and I would have had no reason to raise a fuss in the first place.

I find it truly remarkable that someone ELSE has made a mess of that article and everyone expects ME to magically somehow fix it. It would be one thing if I wanted something truly new under the sun but I'm just asking for it to be put BACK to the way it was BEFORE someone's edit screwed up the statistics section! It should have been done in 5 minutes! Instead I feel like banging my head against a wall dealing with the sheer STUBBORNNESS I keep running into everywhere I turn to point out that the edit that was made to that article has caused it to be in FLAGRANT VIOLATION of a long-established POLICY here! — Preceding unsigned comment added by 70.52.178.195 (talk) 01:21, 22 January 2021 (UTC)

You're at the point where you're not listening, so I'll be moving on. (Btw, "I don't know how to fix it" might have been a much more successful way of going about this than "Fix it, puny humans".) --Izno (talk) 02:00, 22 January 2021 (UTC)

In response to the IP's comments at WT:USE, I said: You can generate and upload the images yourself if you want; we can specify them as a fallback image, apparently, so just tell us the filenames when you're done. The graphs were changed to require JavaScript via T211881, decided by the site admins to which you refer. Avoiding JS is at T249419, and seems stalled because it's hard. Enterprisey (talk!) 03:21, 22 January 2021 (UTC)

Out of technical interest; I encountered a similar situation when working on a JavaScript powered embeddable chess demo thing a few years ago, which would have required image fallbacks. My thought was to use a MW extension to auto generate the required images(via ImageMagick or similar) from the data use by JS, and it seems to me the same approach (although not currently existent) could work for graphs. It could even be implemented as soon as within 10 to 20 years ;) Fred Gandt · talk · contribs 03:54, 22 January 2021 (UTC)

All these T-something-or-other references and the like are just a smokescreen, or at best an attempt at making excuses. MOS:PRECOLLAPSE is still the law of the land until that page says differently, and the people to whom IDHT would seem to apply are the people bending over backwards to avoid acknowledging that point -- and to avoid noticing that the very page at issue has a graph right near the top of the article that has remained viewable without Javascript, thus putting the lie to any claim that it is technically unfeasible to have such a graph (let alone that it magically became unfeasible just a couple of weeks ago, after being commonly done for years and years).

If that graph can remain viewable without Javascript, then they all can. End of debate. — Preceding unsigned comment added by 70.52.178.195 (talk) 16:52, 25 January 2021 (UTC)

Wikipedia:WikiProject Discographies has an RFC

Wikipedia:WikiProject Discographies has an RFC for a possible alternative format for singles discography tables. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Heartfox (talk) 01:32, 22 January 2021 (UTC)

The issue centres on screen readers. I have not seen any regulars from this project supporting the claims nor have I seen anyone rejecting them. Your input would be valuable. Walter Görlitz (talk) 08:47, 29 January 2021 (UTC)

Double spaces

I could've sworn I read it somewhere, but now I'm unable to find it. Any help? --Ineffablebookkeeper (talk) 16:55, 27 January 2021 (UTC)

A single space is the accepted modern style in the post-computer era, as the doublespace was for typewriters and the practice has fallen out of use for various reasons (see Sentence spacing#Modern literature). However, using double spaces after end punctuation is not explicitly prohibited in MOS:DOUBLESPACE. Considering it renders on the viewed page as one space anyway, it definitely seems unnecessary though.— TAnthony^Talk 17:08, 27 January 2021 (UTC)

And to that end, I believe AutoWikiBrowser automatically eliminates double spaces in its genfix function.— TAnthony^Talk 17:10, 27 January 2021 (UTC)

Double spacing is a problem with our new tutorial pages....getting people to care about accessibility for all is hard 😠.....not sure the problem here but Help:Line-break handling has lots of info and links to our guidlines.--Moxy 🍁 17:17, 27 January 2021 (UTC)

I do not believe there has ever been content about double spacing in this guideline. What is it you believe you read? --Izno (talk) 20:09, 27 January 2021 (UTC)

Honestly, something about it not rendering correctly for some screenreaders. I know there's discussion further up this Talk page about how some screenreaders can encode emojis correctly, but that some older ones don't, and that screenreader technology is so extremely expensive that it's impossible to fly by a 'newest-technology first' policy, as the rate of replacement if you've bought a screenreader is likely to be pretty low, meaning you might be running much older software. (If that makes sense.) It would be useful to have some editors more familiar with screenreader technology and how older models handle doublespaces chime in on this. --Ineffablebookkeeper (talk) 16:08, 28 January 2021 (UTC)

I'm pretty certain that no screenreader likely to be in use today is going to be bothered by sentences being separated by double spaces. My advice is to just not worry about it (although I tend to just remove those extra spaces if I'm doing another edit). It saves a few electrons somewhere along the way. Each extra space removed also saves one byte of storage, so if we eliminate around 10 billion of them, we'll save the WMF enough money to buy a cup of coffee. --RexxS (talk) 16:23, 28 January 2021 (UTC)

Ah, but this begs the question...a cup of coffee from where? (/s) --Ineffablebookkeeper (talk) 15:00, 30 January 2021 (UTC)

As a screen reader user ... yep pretty much this. Graham87 02:39, 29 January 2021 (UTC)

Some conversations of interest for page watchers

I'd like to request assistance on a few discussions that could either use a gentler hand than mine or which are generally relevant to this talk page:

• Talk:C shell#MOS and etc.
• Template talk:Endorsements box#Collapse
• Wikipedia:Templates for discussion/Log/2021 February 21#Template:Collapsible section

--Izno (talk) 18:21, 21 February 2021 (UTC)

Font gimmicks

I recently came across skewed text on one editor's User and User talk pages and was surprised that WP:ACCESSIBILITY didn't cover that. We have guidelines on font color and size, and WP:TPG says to Avoid excessive use of color and other font gimmicks, but I think that vertigo-inducing elements should be specifically disallowed site-wide.
The pages are User:Zoozaz1 and User talk:Zoozaz1, which originally looked like this and this. The editor has added a way to opt out of the skewed text, but I don't think an average person is going to notice that. Woodroar (talk) 00:47, 28 February 2021 (UTC)

Here we go again with the nannying of user pages. Jesus, find something useful to do. EEng 03:00, 28 February 2021 (UTC)

People with screenreaders or who are simply visually impaired such that they just have a harder time reading the screen often need to use user pages to contact other users about their work in mainspace. Userpages aren't some fun special homepage, they're a landing page for work communication, like a desk. Customizing them is fine, but making them unusable to segments of the population for purely aesthetic reasons really misses the point. Parabolist (talk) 12:05, 28 February 2021 (UTC)

I'm on the fence about whether (or to what extent) we should allow stuff like this, but I'm having a hard time understanding what this has to do with screen readers. It's just a CSS trick so it'll be read like any other page, won't it? Nardog (talk) 12:12, 28 February 2021 (UTC)

Yeah, sorry, generally when talking about visual stuff I tend to revert to using screenreaders as an example, because people have a much easier time understanding the challenges faced by those users than the ones faced by generally visually impaired users (Where you generally get the 'well everybody doesn't see so well, so I don't really see the difference between me, a sighted person, and someone who's legally blind but not using a reader, or someone with a dyslexic style condition.) But you're correct, this specific issue tends to sidestep that, and I should have prioritized the latter group, to which this is more of an issue, and which represents a wide swatch of different issues and conditions. Parabolist (talk) 12:28, 28 February 2021 (UTC)

While I named this section "Font gimmicks", the principle could apply to images as well. Say, with flash/strobe images that may trigger seizures. Or a gallery of high-resolution images before a Talk page that could make the page inaccessible for mobile users or anyone with slow internet. Woodroar (talk) 15:57, 28 February 2021 (UTC)

The skewing is done purely with CSS, using the -moz-transform: property (which is recognised only by Mozilla browsers) and the -webkit-transform: property (which is recognised only by Webkit browsers). Since these properties are browser-specific, any other browser will show the text unchanged. As far as screen readers are concerned, the effect is nil. --Redrose64 🌹 (talk) 09:07, 1 March 2021 (UTC)

I have no strong issue with the user page being slanted, especially as the user has provided a reasonable alternative to learn about their person.

The user talk page is a different story and definitely crosses the "you need to get over being a special snowflake and allow other people to use your talk page" line. But that probably falls under WP:TPG in spirit if not in wording somewhere. --Izno (talk) 18:56, 28 February 2021 (UTC)

Once upon a time, I had a tilted talk page. I annoyed the hell out of everyone who visited the talk page.

I am not opposed to having tilting of the background, although I believe text must remain vertically aligned with the window. The only exception I would have for this is April Fool's day, but that is it. Aasim (talk) 05:49, 4 March 2021 (UTC)

On going debate at Talk:RuPaul's Drag Race UK (series 2) regarding MOS:TABLE, MOS:COLOUR and more widely MOS:ACCESS

For anyone who is interested, there is currently some intense discussion at the above talk page about tables that are gross violations of MOS access. It is clear that knowledge about accessibility and basic standards of web accessibility are not well understood by the average/casual editor.

If anyone has any additional expertise in this area and would like to comment, please feel free. ≫ Lil-Unique1 -{ Talk }- 20:26, 6 March 2021 (UTC)

Recent changes

I just reverted one change by SMcCandlish which was factually inaccurate. I almost reverted the entire bunch, because there were a lot of changes that were dubious and a matter of one person's opinion. These changes really ought to be discussed beforehand.

The change I reverted contained this:

This is not ideal, because it tells screen readers that there is a list item consisting of "Text here", then another list item that is empty, then a third list item consisting of "More text", when really these are all intended to be a single item in most cases. Because it is faulty markup, various editors will actually remove such empty list-item lines when they are encountered.

That displays a fundamental misunderstanding of how screen readers and the MediaWiki parser work. Screen readers read the rendered html, not wiki-text, and the MediaWiki parser completely removes empty list items from the html. This is the example being considered:

: Text here
:
: More text

This is what it produces:

Text here

More text

Anyone can use the browser inspect function to see that the html produced has a list with only two items, and a screen reader will "see" a list with two items, not three as claimed.

The real point of the "pseudo-blank" line is for editors to more easily find the start of a contribution in threaded discussion in wikitext. The guidance is there to stop editors from breaking the list by placing a blank line before adding their comment. It is not intended for editors to separate out parts of their contribution and so the "new-paragraph markup on the same output line" is not helpful advice. I understand that SMcCandlish thinks that sticking html like <p> is the best idea since sliced bread, but many editors deprecate the use of raw html in wiki-text, and there are better solutions available than re-writing most of the page in html. We have wiki-markup for a reason.

It's quite important when changing guidance to be sure of the changes, and it's courteous to other editors not to do a dozen consecutive, unrelated, undiscussed changes in one batch. --RexxS (talk) 02:14, 8 February 2021 (UTC)

Good point on the suppression of the blank item; I didn't realize MW would do that. Actually, MW isn't doing what you seem to claim it is doing; see below. And it is MW doing it. For example, copy the following into a local "test.html" file and load it in Chrome, and you'll see:

<html><head><title>Empty list item test</title></head><body> <ul><li>List item 1</li><li></li><li>List item 3</li></ul></body></html>

The HTML specs, and most if not all browsers interpreting them, will not "innately" suppress an empty list item; we're just depending on MW to suppress display of empty ones. Because this is at the whim of the devs, who sometimes do weird stuff, we probably shouldn't depend on this blank-item-suppression behavior being a permanent feature.

But even if we did make that assumption, this is all a "just fix it" matter. We don't need to have a big thread about this sort of wording glitch, much less mass-reverting of various unrelated changes. The section was still wrong to suggest this blank : line approach is the only approach. It's a viable choice when but only when the actual intent is two distinct list items. More often than not that isn't the intent at all; it's usually done by editors making long posts and trying to use it for purely visual paragraph breaking and spacing. It's the obviously incorrect approach for that (para. breaks inside the list item are the correct one), so we should be clear on what the difference is. I've now done that, and re-instated the other stuff nuked in your revert. "We have wiki-markup for a reason": Yes, to create simple wiki documents, primarily for sighted users. It was never developed with accessibility in mind, much less to double as a discussion-board threading mechanism. About half the stuff in MOS:ACCESS is just working around lack of foresight on the part of WMF. It's irrelevant that you don't like HTML markup in posts; the exact same effect can be had with {{pb}} for those who prefer templates. Using HTML selectively can make the source much more readable, and give the writer more certain control over the output, but it's entirely optional.
 — SMcCandlish ☏ ¢ 😼  03:02, 8 February 2021 (UTC); revised: 03:27, 8 February 2021 (UTC)

It's actually worse than I thought. I'm not sure if you're somehow getting sent rendered code that I'm not, perhaps due to intervention of some user scripts, but the claim that "Anyone can use the browser inspect function to see that the html produced has a list with only two items" does not appear to be correct (did you actually try that?). I'm looking at the post-parser source my browser is receiving from User:SMcCandlish/sandbox22 (which tests three kinds of MW-markup lists and a bare-HTML one). Also tested at User talk:SMcCandlish/sandbox22, just in case talkspace behavior is different (which it eventually may be). The code MW sends to the user agent has <li class="mw-empty-elt"></li> for empty list items in ordered and unordered lists (whether created through explicit HTML or with * and # markup). So they are still present, and we're depending on the user agent to accept a CSS class's instruction to suppress rendering (which may be a reasonable dependency/assumption these days, even for screen readers). However, with description lists (i.e., what our talk discussions are mostly structured with), the browser receives a raw <dd></dd>, which is exactly what you said is not happening.

The important thing for this segment of this MoS page is whether : as a blank "spacer" line is actually going to produce an annoying "nothing" list item in screen readers, or will just be skipped by them. I don't think it really matters who did less testing than they should have (seems to be both of us!) I suspect that them being skipped is actually true, but Graham87, who seems to test-drive a lot of screen readers, can probably confirm one way or the other. Regardless, the blank item not existing in what MW sends to the browser can't be a factor (because it does exist in what the browser receives after all, and not even with CSS class aimed at hiding it). And the blank-:-line technique, even if it works, is still the wrong one to use for most cases because they're intended to be single posts (single list items).
 — SMcCandlish ☏ ¢ 😼  03:27, 8 February 2021 (UTC)

which may be a reasonable dependency/assumption these days, even for screen readers Graham has verified as such of late. --Izno (talk) 03:43, 8 February 2021 (UTC)

Glad to hear it. In the interim, I clarified the examples in that section to get at what RexxS is talking about above, about use of a blank : line between comments of editor A and editor B at the same indentation level. And I changed the <p>...</p> example to use {{pb}} since it's more wiki and less HTMLy. :-)  — SMcCandlish ☏ ¢ 😼  03:54, 8 February 2021 (UTC)

I actually did check the example I gave and only read two list items. On investigation in your sandbox, it becomes clear that the MW software suppresses the blank list item by setting it to display:none. That removes it from the DOM tree for both browsers and screen readers, and that's why nobody sees or hears it, but it's visible in the source code. My point about how it's not voiced by screen readers still stands. I also stand by my assertion that preceding a contribution by a pseudo-blank line is the only viable advice to give to editors who wish to make their post appear more separate from others in the wikitext. --RexxS (talk) 04:26, 8 February 2021 (UTC)

That seems reasonable enough, and the page still says this. So, is there still an issue to resolve?  — SMcCandlish ☏ ¢ 😼  03:16, 22 February 2021 (UTC)

No, you seem to have made a good job of sorting that out now, Thanks. --RexxS (talk) 16:52, 22 February 2021 (UTC)

(edit conflict) Yes, I know it's MW that suppresses the empty list item if it's created using wiki-markup. That's why I told you that was what happens. It's exactly what happens to the line above this, whose only purpose is to help editors see that your contribution ended and mine began.

I don't need to paste a test file into Chrome; I'm quite capable of reading html as I've been writing it for over 25 years, and I understand quite well how it is rendered. But we're not writing html; we're on a wiki, and we're writing wiki-text.

None of this is at the "whim of the devs" and we don't need to write wiki-pages in html to pre-emptively prevent some imaginary breaking change being made. That's not going to happen and we really should depend on the blank-item-suppression behaviour being a permanent feature.

You need to discuss potentially controversial edits before making them. I reverted precisely one of your twelve consecutive undiscussed edits. So don't ever shout at me in your edit summaries again, as I did not "MASS-REVERT" anything. If you insist on making a fuss about my single revert, I really will revert your entire set of edits and we can go through them here, one at a time, to reach a consensus on each change. Try me if you want to make a point about your right to make undiscussed edits to the MOS.

The section was exactly right to suggest that the the pseudo-blank line (:) approach is the only viable one. Separating two editors' comments in a threaded discussion is by far the commonest use of the technique; it is pointless to use it inside a single editor's contribution, and we should be discouraging any such use.

Your advocacy of <!-- --><p> is inappropriate. In threaded discussion starting another list item works perfectly well for colon-indents, and use of {{pb}} is simple for bulleted items. Nobody needs your complicated and unnecessary use of html. The MOS isn't the place for you to push your own idiosyncratic style of editing.

If you don't like having one edit out of twelve reverted, start from the assumption that you ought to be discussing before amending MOS, and only make small uncontroversial changes. If there were multiple unrelated changes made in a single edit, then expect the lot to be reverted when someone objects to part of it. Don't expect other editors to waste their time cleaning up your lack of forethought.

It doesn't matter what the provenance of our discussion system is, although I should point out that the misuse of definition lists to create indents dates back to at least the late 1990s, well before the MW devs copied the idea. The point is that we have crafted, not without some effort, a series of simple work-arounds that makes the experience of using Wikipedia at least tolerable for screen reader users, and we don't need your fixations with html to complicate advice that has been shown to work.

So, I'm going to ask you nicely, before you start another campaign to persuade editors to adopt your way of doing things, please run it past the editors here first, and try to gain some consensus before launching it. --RexxS (talk) 03:56, 8 February 2021 (UTC)

How important is the empty-list-item workaround? There are parser changes in the works (not very soon), and there is no guarantee that it will continue to be treated the same way. Whatamidoing (WMF) (talk) 04:03, 8 February 2021 (UTC)

The talk page tooling will probably make it unnecessary entirely. (And/or the new syntax for discussions, if/when that is worked.) --Izno (talk) 04:08, 8 February 2021 (UTC)

@Whatamidoing (WMF): the problem I'm regularly faced with is this: an editor wants to add a comment to a talk-page thread that has a lot of comments and wants to ensure that the start of their comment is easier to find in the wikitext, perhaps when previewing or when coming back to add to their comment. Their natural inclination is to add a completely blank line before their comment because it doesn't alter the rendering (much) in the browser. Unfortunately the blank line closes all of the nested lists being used to produce the indentation, and then it opens an equal number of new nested lists before the text of their comment. That is unnecessarily annoying for screen reader users and we need to avoid that happening. Without any shadow of doubt, the simplest, most understandable advice we can give to editors to fix that problem is to place the same number of indent markers on the otherwise blank line (creating what I called a 'pseudo-blank' line). That completely removes the problem of unwinding one set of lists and winding up another set because the lists simply continue at the same level. The parser never sees a blank line that forces it to close the lists.

I apologise for taking the time to explain what we probably all already knew, but the point I want to make is that I've experienced a lot of success in explaining the technique to editors who were unaware of the problem caused to screen reader users; and having clear, simple guidance in MOS:ACCESS that I can refer them to is very helpful. That's why I don't want SMC overcomplicating things and fucking up a piece of guidance that I've found to be successful in educating sighted readers on how to avoid the problem. --RexxS (talk) 04:52, 8 February 2021 (UTC)

Yup, replying in the middle of a long discussion is painful. Even replying at the end is difficult; you have to scroll forever. Would you (all) please click https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Accessibility?dtenable=1 (requires Javascript) and check out the little "reply" buttons it will add at the end of each comment? If you're in it's 'visual' mode, type the @ symbol and ping me, too.  :-) Whatamidoing (WMF) (talk) 19:39, 8 February 2021 (UTC)

@Whatamidoing (WMF) That's pretty neat.

However, I don't think you should have to hit an "Advanced" link to leave a proper edit summary. And it's pretty ironic that I'm looking at text that's 75% of base font size on a MOS:ACCESS page, when the bright-line, absolute minimum text size is 85%.

No, I'm not going to follow the link to share feedback on the grounds that it's too damn small for me to read. -- RexxS (talk) 01:24, 9 February 2021 (UTC)

Once you click the "Advanced" link, it stays open in all subsequent replies, unless and until you close it. Since most people either don't add an edit summary (or get an automatic one, such as new section) or add an uninformative one (c, comment, r, reply), then having it default, for replies, to Reply, seems reasonable to me. I just looked through about 40 or 50 edits to talk pages, and I found only one informative, non-automated edit summary for a reply. That editor had simply copied and pasted his entire comment into the edit summary field. Almost everything else was either absent or automated.

I asked about the font size some months ago; at the time, they said that it was the same font size used for that message in one of the other editing environments, but I don't remember what the specific point of comparison was. I have set a minimum font size in all of my web browsers, so it's easily readable by me. Whatamidoing (WMF) (talk) 19:57, 9 February 2021 (UTC)

Yes, I tested it out in one of my sandboxes and was pleasantly surprised to find the 'Advanced' had stuck. Unfortunately, I'm not most people and I like leaving some sort of relevant edit summary (even "reply"). I expect I'm not the only one, and you can peruse the page history of this talk page to confirm that.

Well, the next time you ask about the font size, please point out to them that just because another editing environment puts up with with shitty accessibility, this editing environment isn't going to. No text (with the exception of the tiny superscripts used for references) should ever fall bellow 85% of the base font size for the page. It's nice to be able to set a minimum font size in your browser, but if you try doing that in a library, school, or workplace, you'll find the IT Crowd who own those computers will almost invariably forbid any changes to settings. It's important for devs and testers to retain as many default settings as possible because they need to see what the average reader sees, so you really ought to turn off your minimum font size when you're on work time. --RexxS (talk) 21:32, 9 February 2021 (UTC)

No, I really oughtn't turn off features that make the web accessible to me, and I'm surprised to see you even suggest that people with vision problems shouldn't make full use of the accessibility tools available to them.

The design team has rules about accessibility; you can read some of them at https://design.wikimedia.org/style-guide/visual-style_typography.html. I doubt that it says anything about assuming that any percentage of locally set sizes is going to be accessible. Whatamidoing (WMF) (talk) 19:32, 10 February 2021 (UTC)

Yes, you really should turn off any features that you can't expect a significant minority of readers to be able to use. Unless you understand how readers see the page, you're in no position to judge what problems they will experience. You can't expect all users to be able to set a minimum font size, so you shouldn't enable it yourself. I certainly don't, and I don't recommend anyone who does development or advocacy work to do so either. Of course, the rest of the readership, not involved in development or advocacy, work should employ whatever accessibility tools they can use to improve their experience. That's a good thing until they fail to understand the problems caused to those unable to use the same tools.

Have another look at the Use of styles section in the Visual Style - Typography page. You'll see the recommendation for "Body, Paragraph" text (what we call the page's base font size) to be set to 16sp and "small text" to be set to 13sp. The smallest text they recommend is 81.25% of the base font size. That's below our minimum size of 85%, but is almost as close as you can get using integer font sizes (14sp would be more acceptable at 87.5%). There is certainly no example on that page of text that is anywhere near the 75% used for the [Advanced] link that I complained about. The reason why MOS:TEXTSIZE works with a percentage is that most readers will adjust the zoom on their browser so that the vast majority of the text is displayed at a size that is most comfortable to read. That then limits the smallest font size that older folk or those with impaired vision can manage to read, and there has been general agreement that 85% represents that absolute lower limit. We should never expect our readers to zoom in and out on parts of a page simply because the designers are ignorant of the problems posed by making fonts too small. --RexxS (talk) 20:49, 10 February 2021 (UTC)

RexxS, you're being a jerk. Would you tell Graham to stop using a screen reader because 99% of us don't have screen reader software or know how to use it? Of course you wouldn't: That's what makes the web accessible to him, and that's what we're here for on this page. By exactly the same standards, you shouldn't tell me that I shouldn't use the accessibility features that make the web accessible to me, just because some other people might not know how to use their software, or have access to the software that fits their needs.

I suspect that what you meant to say is that somebody who is not me (e.g., someone whose job title includes the word "designer") should consider experiencing the site they're designing in multiple formats, including on different screen sizes, in different browsers, with goggles that simulate different vision conditions, etc. WhatamIdoing (talk) 02:33, 15 March 2021 (UTC)

This is over my head and I don't know if what I'm about to say is relevant, but I previewed the following in a sandbox:

: Text here
:
: More text

Viewing the HTML source showed:

<dl><dd>Text here</dd>
<dd></dd>
<dd>More text</dd></dl>

Johnuniq (talk) 06:15, 8 February 2021 (UTC)

Both NVDA and JAWS read almost all the lists in User:SMcCandlish/sandbox22 (as having two items; the only exception is JAWS, which doesn't enumerate definition lists. Graham87

Relevant discussion at MOS:TABLE

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/Tables#Conflicting guidance on headers, which concerns MOS guidance on "year" and "title" columns in tables (specifically, which column should be the rowheader, and the ordering of the two columns). — Goszei (talk) 06:36, 24 March 2021 (UTC)

Was about to cross-reference this also, as it now involved rowspan and accessibilty, as well.  — SMcCandlish ☏ ¢ 😼  10:12, 3 April 2021 (UTC)

See also Wikipedia talk:WikiProject Discographies#RfC: Possible alternative to current singles discography tables, an RfC expected to close pretty soon, and probably taking insufficient account of accessibility needs.  — SMcCandlish ☏ ¢ 😼  15:54, 3 April 2021 (UTC)

Highest-grossing franchise template

I recently came across List of highest-grossing films#Highest-grossing franchises and film series, which surprised me in the number of accounts on which it violated this guideline, mostly through Template:Highest-grossing films franchise, which is used in 21 other articles. I thought someone here might want to take a crack at improving it. Nardog (talk) 01:02, 7 April 2021 (UTC)

I'm afraid I can't, as I have suddenly become violently ill. At first, I was just able to fight back a strong gag reflex, but then I saw that it is a featured list, and just lost it. I may have to leave the task to those with stronger stomachs. — JohnFromPinckney (talk) 01:40, 7 April 2021 (UTC)

Accessibility test using Orca

Iran11y and Psychoslave ran a test of the French Wikipedia using Orca (assistive technology). The report is at m:Accessibility of Wikipedia, a March 2021 use test session. I think it may be interesting to the regulars here as well as to the MediaWiki devs. Whatamidoing (WMF) (talk) 01:06, 9 April 2021 (UTC)

@Whatamidoing (WMF): I've commented at the talk page of the Meta page. Graham87 03:08, 9 April 2021 (UTC)

Preview warnings and hatnote TemplateStyles

Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno (talk) 01:08, 23 April 2021 (UTC)

How do you end a sublist but continue with another paragraph in the same item.

I tried the following:

* '''Agree''' because of
** Reason 1
** Reason 2 {{pb}} This should be a new paragraph in this vote after the sublist.

It renders as follows:

• Agree because of
  • Reason 1
  • Reason 2
    This should be a new paragraph in this vote after the sublist.

The new paragraph shows as a paragraph in the second item of the sublist. This is not what I want. Dominic Mayers (talk) 22:06, 23 April 2021 (UTC)

If I understand you correctly, you want a single list item to contain three components: (i) some text; (ii) a sublist; (iii) some more text. You can't do this in Wikimarkup, but you can do it in HTML, like this:

• Reason 1
• Reason 2

As you can see by examining the page source, my post consists of a <dl>...</dl> element, containing a single <dd>...</dd> element, itself containing a block of text within which is a <ul>...</ul> element. The closing </li> tags are not required in HTML5, but they make it neater. --Redrose64 🌹 (talk) 23:00, 23 April 2021 (UTC)

Thanks a lot. This is what I needed. Dominic Mayers (talk) 05:57, 24 April 2021 (UTC)

HTML can be very explicit about the scope of each item, exactly as you mean semantically. You want:

• Agree because of
  • Reason 1
  • Reason 2

  This should be a new paragraph in this vote after the sublist.

so the "This..." goes outside the close of the sub-list but still within the list-item of the main list. DMacks (talk) 02:43, 27 May 2021 (UTC)

Has something changed about using ! mid-table as a header?

When designing our tables at Tennis Project six or seven years ago, we were told over and over by wikipedia accessibility patrols never to use ! mid table. It was only to be used at the top as a header. It became problematic for some screen readers to see new headers in an unusual place and it was not proper html. Plus editors started using it as a replacement for bolding in tables. Example:

• |style="background:#efefef; text-align:left;" |[[Australian Open]] was fine
• !style="background:#efefef; text-align:left;" |[[Australian Open]] we needed to avoid

We redesigned many tables based on this info from WP:accessibility and it was confirmed by those who used screen readers. No problems. But now I see scope being used with ! at the start of a new row. Did something change with screen readers to allow the ! with the term scope? Shouldn't even scope be used with | throughout the table? In the example style above we also found editors incorrectly using ! to simply bold terms and grey in cells with a non-standard grey that didn't match |- style="font-weight:bold; background:#efefef;". We corrected all our tables at Tennis Project to conform but now I see editors using an exclamation point with the scope term. Does using "scope" fix all these issues with the exclamation point? Thanks. Fyunck(click) (talk) 19:16, 28 May 2021 (UTC)

Please provide links to the pages where this problem occurs. --Redrose64 🌹 (talk) 19:43, 28 May 2021 (UTC)

Here is an example in my sandbox. Fyunck(click) (talk) 22:20, 28 May 2021 (UTC)

See Wikipedia:Manual of Style/Accessibility/Data tables tutorial. Nardog (talk) 22:29, 28 May 2021 (UTC)

I did look there and I see the use of scope with an exclamation point. So am I to assume that when using scope with an exclamation point it supersedes the old recommendation and that all screen readers can handle this use of an exclamation point? Because without the scope parameter it did cause issues. I assume we can also use scope without an exclamation point if we don't want the column greyed out or bolded? Because we also get hit with overbolding that column when we submit it for good article consideration. Or do we simply use plainrowheaders to wipe out the bold? Not sure what to do to wipe out the grey background if we must use !. Fyunck(click) (talk) 23:15, 28 May 2021 (UTC)

In a table, there are two kinds of cell: header cells and data cells, and screen readers announce them differently. For sighted people, in the absence of other formatting, header cells have a light grey background and centred bold text, whereas data cells have a white background and left-aligned normal-weight text. Header cells (but not data cells) may use the scope= attribute to show what the header cell is the header for: scope=col means that it is the header for all of the data cells below it in the same column, whilst scope=row means that it is the header for all of the data cells to its right in the same row. If omitted, scope=col is assumed.

In Wikimarkup, we format a cell as a header cell by using an exclamation mark, and we format a cell as a data cell by using a pipe.

It should never be necessary to boldface the text in a header cell. --Redrose64 🌹 (talk) 23:33, 28 May 2021 (UTC)

Interesting. And if you don't want the header cell bolded you don't remove the ! with "scope", you simply use plainrowheader at the beginning of the table? Who determines whether the far left column is a data cell column or a header cell column? Or is that creator or wikiproject choice? In the examples I gave it seems the only thing that must be a header is the top row. The left side column is sort of 50/50 and we were specifically told multiple times not to treat it as a header in the past. But that was without using the scope parameter. Fyunck(click) (talk) 00:33, 29 May 2021 (UTC)

If it's really a data table, why would the left-most cells not be headers? That's the classical arrangement of data in a table. We make a matrix of items described by a top row woven together with a column of items described by a left column.

I can't say what you were told earlier, or why (or what was really meant, perhaps as a simplification due to limitiations of the time), but I expect a table to have column headers with scope="col" and row headers with scope="row". If the table works best in an article without bold centered row headings, I use plainrowheaders (note the "s" at the end). And I would not make a table exactly like any of the three examples in your linked sandbox page. — JohnFromPinckney (talk / edits) 00:48, 29 May 2021 (UTC)

Fair enough. As far as the second table in my example... we weren't just told, we worked with those with screen readers to make sure there were no issues. Table two, with exclamation point headers but not using scope, gave their screen readers troubles. So it wasn't just that we were told by those astute at WP:Accessibility, we had proof it caused problems. This was back in 2014/15. It seems clear here that using an exclamation point with scope works fine. And using "|" and adding background color for the cell to #EFEFEF and set to bold (or not bold) also works fine with accessibility. It's then a question of whether it's a data cell or a header cell. Fyunck(click) (talk) 01:08, 29 May 2021 (UTC)

Um, okay, but hang on: you shouldn't have to be adding #EFEFEF or bold to anything. Part of wikitable styling is that it automatically and consistently formats table headers. If you're mucking around with background colors you're either doing something rather special or wrong. — JohnFromPinckney (talk / edits) 02:55, 29 May 2021 (UTC)

Well the issue is whether they should be headers. In most of our tennis project charts we do not consider the left column as a header, so no "!" and we use efefef and sometimes bold. And when we use headers (!) we usually want the bold removed. Plus we often need an entire row with grey background, not just the first cell. But yes, some of our tables are quite unique. Fyunck(click) (talk) 07:25, 29 May 2021 (UTC)

To answer your question, in your sandbox, the Tournament cell (the one with the tournament name) in each row is indeed the row header and should have ! scope="row" |. --Gonnym (talk) 07:50, 29 May 2021 (UTC)

We may not agree on that, but let's say we do. I know how to make it unbolded with plainrowheaders. How can we make it with no grey background? So transparent? Fyunck(click) (talk) 08:11, 29 May 2021 (UTC)

Never mind... it looks like you can do it with style="background:transparent". Thanks everyone for the help. Much appreciated. Fyunck(click) (talk) 08:21, 29 May 2021 (UTC)

I apparently failed to make myself clear. The consistent representation of row headers with the shaded background is a feature, and something that helps our readers readily identify the table headers. Why would you want to conceal that important information? You seem to want to make it harder for readers to parse the contents of your tables. Please leave the default shading for the row headers, and consider leaving the default bolding of them, too (although this doesn't always look so good, e.g., when the headers are linked); if you can't, then apply plainrowheaders, but nothing else. — JohnFromPinckney (talk / edits) 17:08, 29 May 2021 (UTC)

That will be up to the project. As for bolding, we have been scolded by article reviews for too much bold, charts included. As for the chart color there is nothing wrong with a white background at all. The look is much cleaner. If it works better for the sight challenged to have a header row using scope, we will accommodate that. Otherwise it's up to the project as far as charts in tennis article. I just came here to find out if a particular style was ok to use, and i thank you for that. Fyunck(click) (talk) 19:03, 29 May 2021 (UTC)

That will be up to the project. - this sounds like WP:LOCALCONSENSUS. Please do not compromise the semantics of the page for the sake of visual appearance. --Redrose64 🌹 (talk) 19:14, 29 May 2021 (UTC)

ACCESS is not a local consensus. It would apply to all of the English project. We can address when other projects choose to ignore accessibility issues. Walter Görlitz (talk) 19:16, 29 May 2021 (UTC)

Actually there is nothing that is required as far as this coding goes. That's why the parameters exist. Not every chart has to be identical and aesthetics plays a huge role. If it works better for a screen reader to make it a header because it reads different, we work with that. But if we can also at the same time make it better for those with sight, we work with that too. This isn't a policy issue. Local consensus on some things is perfectly fine and the creation of certain tennis charts is the province of that wikiproject. It is not required to be bolded, it is not required that it be grey, it is not even required that it be a header where we use "scope." Thanks. Fyunck(click) (talk) 19:48, 29 May 2021 (UTC)

Sorry, no: it is not even required that it be a header is just wrong. Headers should be headers. That's why you should use the exclamation point (!) in wikicode for all the header cells. It produces <th> cells in the HTML. The "scope" is to clarify whether the th cell is a column heading or a row heading. They are not optional or mix-and-match. I don't think (although I'm not 100% sure) that the scope attributes even have any effect on a <td> cell.

As far as aesthetics go, surely you can see that a table that is easy to read and is consistent with the majority of tables on Wikipedia has aesthetic advantages, yes?

And finally, yes, it is a policy issue. Just flip over to the project page of which this is the talk page, and read the first two paragraphs. — JohnFromPinckney (talk / edits) 20:49, 29 May 2021 (UTC)

@JohnFromPinckney: The th and td elements share most of their attributes - what is valid for one is usually valid for the other, but scope= is an exception, being only valid for a <th> tag. The corresponding attribute for a <td> tag is the headers= attribute, but that's much more complicated to use. --Redrose64 🌹 (talk) 22:29, 29 May 2021 (UTC)

Great, thanks for the confirmation. I "know" about headers=, but haven't had the pleasure of trying to use it. — JohnFromPinckney (talk / edits) 22:32, 29 May 2021 (UTC)

@Walter Görlitz: My comment about LOCALCONSENSUS is not about a local consensus of the accessibility project, but of a local consensus formed by the tennis people that their tables should be formed in a certain way that goes against the rest of Wikipedia, accessibility included. Such unusual formatting (not just with tennis, but by the likes of the football and motor racing people) is the kind of thing that RexxS was striving against. --Redrose64 🌹 (talk) 20:29, 29 May 2021 (UTC)

Thanks for the clarification. Agreed. A project's decision does not override a site-wide decision of this importance. Walter Görlitz (talk) 20:43, 29 May 2021 (UTC)

MOS:ACCIM question

I've got a question about WP:ACCIM. How or does it apply to the use of images such as File:Symbol venus.svg in articles like Astronaut birthplaces by US state? FWIW, I totally get the visual appeal of using the symbol next to the names of women astronauts, but at the same time it seems a bit cluttery and not really necessary for encyclopedic reasons since all of the individuals listed have a stand-alone article written about them. My main concern is though is whether it creates access issues for visually impaired or maybe even those looking at the moblie version of the article. Are there any such issues which need to be addressed? Does anyone know how a screen reader might treat such an image? Does it just say the file's name when it comes to it or does it say something like "female"? I know that there's an |alt= parameter that can be used in the image syntax, but that doesn't seem to be the case with respect to this article. -- Marchjuly (talk) 00:46, 20 June 2021 (UTC)

Yes, a sccreen reader says the image filename. If it's decided this special marking of women astronauts is necessary, wouldn't it be better to make a template for that which could include the alt text? Graham87 01:54, 20 June 2021 (UTC)

NavFrame removal (soon)

Page watchers may be interested in WT:MOS#NavFrame removal (soon). Izno (talk) 21:50, 28 July 2021 (UTC)

Pangaea gif

See Talk:Pangaea#Animation_of_Pangaea_breakup there is a discussion about whether a gif is in violation of accessibility guidelines. Hemiauchenia (talk) 16:51, 8 August 2021 (UTC)

the gif in question

Text in templates unreadable on mobile dark mode and missing

I've noticed that the episode templates on our articles about TV shows can be problematic. These problems tend to fall into two categories: either the text is colored such that is in unreadable on dark mode wikipedia app, such as this example, or portions of the text flat out doesnt appear example of missing titles and another missing titles. I dont know if this is a fault of poor color choice, an oversight in the templates, or an issue with the mobile app itself. ^Thanks,L3X1 ◊distænt write◊ 15:30, 21 May 2021 (UTC)

Which mobile device and which mobile browser? My iOS Safari has no problems with these in dark mode because it does not change the browser rendering, only the skinning. Walter Görlitz (talk) 15:38, 25 May 2021 (UTC)

I am using the Wikipedia app (version 6.8.1) on iOS14.4.2 on a iPhone 8. I have some screenshots which I can upload if desired. ^Thanks,L3X1 ◊distænt write◊ 02:38, 27 May 2021 (UTC)

That appears to be the current version. I would go to the app store and look-up the app. Click through the App Support link and let them know about the problem. It probably has to do with h ow they've implemented dark mode. I'm sure that they can work with Media Wiki to fix the table formatting. Walter Görlitz (talk) 05:39, 28 May 2021 (UTC)

will do! ^Thanks,L3X1 ◊distænt write◊ 14:46, 1 September 2021 (UTC)

Fixed image size templates

I have noticed that there still a few templates that require fixed image sizes. Examples are {{wide image}}, {{tall image}}, {{panorama}} and {{panorama 2}}. There are also infoboxes, such as {{infobox football biography}}. I have commented at the latter, but do not have the skill to modify these templates, not to mention the issues about converting all of the pixel sizes to relative sizes. Granted, the templates I have listed here are usually larger anyhow, so they may not need to change. Walter Görlitz (talk) 20:46, 8 September 2021 (UTC)

Discussion at Talk:List of screw drives § Images in Section Headings

 You are invited to join the discussion at Talk:List of screw drives § Images in Section Headings. — Marchjuly (talk) 04:09, 15 October 2021 (UTC)

WP:LIST ACCESS

It is my hope that this new shortcut will end up being used instead of MOS:LISTGAP. My reason for creating it is a discussion I had a while back that went something like this:

<editor 1> Hey this project space page isn't formatted right

<me> it isn't?

<editor 1> It doesn't follow MOS:LISTGAP

<me> project space generally does not have to follow the MOS

<editor 2> I guess you just hate blind people

<me> wait... what?

<editor 2> what are you going to tell <editor 3>, who has to use a screen reader, that you just don't value them? That they deserve to suffer because you find it inconvenient?

<me> I thought we were talking about the manual of style?

Now obviously editor 2 there could've taken a different approach and explained that we were talking about accessibility, not just style, or I could have followed the link and read the section and realized it for myself, but maybe this will help avoid future misunderstandings of this nature. Beeblebrox (talk) 22:53, 21 November 2021 (UTC)

I don't think we need any more shortcuts (and we don't normally put spaces in shortcuts, either). Your new one performs exactly the same function as the existing shortcuts MOS:LISTGAP, MOS:LISTGAPS, WP:GAPS, WP:LISTGAP and WP:LISTGAPS. The "MOS is only for articles" fallacy is why I normally use WP:LISTGAP. Similarly, we have a related function performed by the four shortcuts MOS:INDENTGAP, MOS:INDENTGAPS, WP:INDENTGAP and WP:INDENTGAPS which in action are identical to each other. When not referring to articles, I normally use either WP:LISTGAP or WP:INDENTGAP, depending upon the context; sometimes I direct people to WP:COLAS. None of these have the MOS prefix. --Redrose64 🌹 (talk) 00:10, 22 November 2021 (UTC)

Obviously I wasn't aware of all those other shortcuts, but maybe one or more of those should be the prominent ones posted on the page instead of MOS:LISTGAP? Beeblebrox (talk) 00:17, 22 November 2021 (UTC)

Here's some of the history. I created the first of these (WP:LISTGAP) more than ten years ago, and Graham87 added the next (WP:LISTGAPS) in December 2012. The next two (WP:INDENTGAP and WP:INDENTGAPS) were added in June 2013 by Dmcq. WP:INDENTGAP was altered to MOS:INDENTGAP in March 2016 by Voidxor; and later the same month the plural forms (WP:LISTGAPS and WP:INDENTGAPS) were both removed, and WP:LISTGAP altered to MOS:LISTGAP by SMcCandlish The others (MOS:LISTGAPS, WP:GAPS and MOS:INDENTGAPS) have never been shown in shortcut boxes. So although the MOS: forms are the only ones presently displayed, that wasn't always so - and the WP: forms have existed for far longer. One reason that we don't display more than one or two is given at WP:2SHORTCUTS, second paragraph. --Redrose64 🌹 (talk) 21:36, 22 November 2021 (UTC)

I know my view is less popular, but I like to encourage the use of descriptive text, rather than all-caps shortcuts in the visible text. For talk page threads, I typically will point to Help:Talk pages § Indentation, referring it to as guidance on talk page formatting. isaacl (talk) 00:48, 22 November 2021 (UTC)

FWIW I agree ... due to a personal hatred of unexplained abbreviations, not just due to accessibility. Also see Wikipedia:WTF? OMG! TMD TLA. ARG!. Graham87 03:59, 22 November 2021 (UTC)

I personally don't mind the all-caps shortcuts (though I'm not on the receiving end of them usually), but do agree that the space in it is odd; WP:LISTACCESS would look better to me. It would also be possible to include one of the WP shortcuts in the sidebar (though it might be a bit silly to include both MOS:LISTGAP and WP:LISTGAP). (For what it's worth, I adjusted the location that all of those shortlinks go to a few months ago.) --Pokechu22 (talk) 04:04, 22 November 2021 (UTC)

My thoughts on the proliferation of shortcuts can be found at Wikipedia talk:Requests for adminship/Optional RfA candidate poll/Archive 5 § Shortcuts. I appreciate why people like them, but the habit of English Wikipedia editors using them unadorned in text results in many different jargon terms that mean the same thing, and this is a barrier to clear communications between editors. isaacl (talk) 05:14, 22 November 2021 (UTC)

I completely agree that having multiple shortcuts in common parlance to refer to the same policy or guideline is confusing. If I remember my frame of mine correctly from five years ago (my edits that Redrose64 referenced above), I was trying to address exactly that. Many of the duplicate shortcuts came about because the ones in the Manual of Style usually acquire at least one "MOS:" prefixed shortcut and at least one "WP:" one.

It is unusual for me to create shortcuts, because I agree that we have too many already. But again, I think my frame of mine in 2016 was consistency. I was addressing the inconsistencies by predominately showcasing the "MOS:" prefixed ones in the shortcut boxes within the Manual of Style. I personally don't follow the frustration with the "MOS:" prefixed ones voiced above (all due respect) for two reasons:

• The shortcuts we are discussing are pointing to a location within the Manual of Style. Favoring use the "WP:" one over the "MOS:" one doesn't negate that fact.
• I completely disagree that the MOS only has standing within article space. I make MOS-type corrections in other namespaces all of the time. It helps with accessibility, and it sets a good example for editors.

– voidxor 21:57, 22 November 2021 (UTC)

It's a matter of emphasis. Uniform writing style is enforced in articles to improve the reading experience. Leaving aside accessibility issues for a moment, editors are more flexible on project pages. In particular for talk pages, primacy is given to preserving the text and (to a large extent) the text's appearance from each comment's author. Sure, we could go around making spelling corrections and style edits that preserve meaning (most of the time, it doesn't matter if "two" is substituted for "2", for instance), but these types of changes can be perceived as being uncollegial, overly focusing on form rather than content. It could become quite distracting if everyone is constantly copy editing each others comments to fix typographical and style issues.

Regarding accessibility, best practices ought to be followed even in discussions, but there's often resistance to changes that alter the appearance (such as the list nesting level) or that would constrain the author (such as being more strict about having descriptive link text). (For example, some editors like linking individual words.) So while following manual of style guidance is generally a good idea on project pages and in discussions, it's not something that the Wikipedia community has embraced as needing to be rigidly followed in those circumstances. isaacl (talk) 01:31, 23 November 2021 (UTC)

I went ahead and deleted the one I made, there obciously does not need to be yet another shortcut for the same section, but I would still prefer something that made it clear that this is an accessability issue as opposed to a matter of house style. Beeblebrox (talk) 00:19, 23 November 2021 (UTC)

Be bold and massage the wording. If we do have another shortcut, it should start with "MOS:", and it shouldn't have a space in it. No one uses shortcuts with spaces in them, which I think we'd all have realized by now.  — SMcCandlish ☏ ¢ 😼  00:50, 23 November 2021 (UTC)

yeah, I got nothing on that point. Seems super obvious now but at the time it didn't occur to me. Beeblebrox (talk) 01:08, 23 November 2021 (UTC)

How do I add a background color to a gallery so that white symbols are visible?

I'm updating some of the symbol galleries on commons, and tried gallery style="background-color: black". However, while that adds a black background to the gallery as a whole, each cell still has a white background. How can I change the latter? (The images themselves have a transparent background, that's not the issue.)

Thanks — kwami (talk) 02:46, 4 January 2022 (UTC)

Ah, figured it out for anyone else who's looking: set mode=nolines. — kwami (talk) 09:57, 4 January 2022 (UTC)

Badly constructed HTML lists at List of sailors at the Summer Olympics

I'm at a loss for what to do with this one ... and fixing it might require a lot of manual work. Basically it uses bullet characters instead of proper HTML list markup, which affects screen reader users like me because it makes it more difficult to move between list items, and it probably abuses layout tables. I've added alt text to the male/female pictograms, once I figured out what they were actually for, but the other issues should be addressed as well. Graham87 15:36, 4 January 2022 (UTC)

Ick. But I think I can fix (or at least improve) that relatively quickly. Let me give it a go, and you can check my work. — JohnFromPinckney (talk / edits) 18:41, 4 January 2022 (UTC)

@Graham87: Okay, I'm still working on it, but I've table-fied A through D. Tell me what you think. — JohnFromPinckney (talk / edits) 19:03, 4 January 2022 (UTC)

Have laid down my tools regarding that page. Feedback welcome. — JohnFromPinckney (talk / edits) 19:53, 4 January 2022 (UTC)

@JohnFromPinckney: Wow, thanks very much, sounds great now! Graham87 01:20, 5 January 2022 (UTC)

Font size in images

I was wondering if the font size (min 0.85x normal font size) also applies to images. In particular, would this figure at effects of climate change be in line with accessibility guidelines? I would argue it's an accessibility issue, but of course, it's possible to enlarge images by clicking on them.. Femke (talk) 10:57, 15 January 2022 (UTC)

At the default width (220px) text in such images would certainly be unreadable even for people with normal sight. --Redrose64 🌹 (talk) 22:45, 15 January 2022 (UTC)

True, on my old iPhone 7 in portrait mode, the text is not readable without spreading fingers, which cuts the diagram off on the left or right. However, landscape mode with finger spreading to fill screen to left and right margins, is easily readable. Do the accessibility standards you mention, expect viewers not to have to zoom or spread their fingers? Is doing so truly an accessibility issue? (P.S. The image in the indicated article is at upright=1.75 to match a picture gallery.)—RCraig09 (talk) 19:53, 18 January 2022 (UTC)

Discussion at Wikipedia talk:WikiProject Weather

There is a discussion at WikiProject Weather regarding the accessibility of track maps, templates/infoboxes, and timelines for the colorblind community. Feedback would be appreciated. Noah^Talk 22:04, 21 March 2022 (UTC)

Closed RfC, looking to add some text to this section of the MOS, seeking input (NOT a new RfC)

Hi all,

So there was an RfC on the suggestion to place a space beneath each heading (see here), which I initiated in order to have the option to add a single line of space underneath a section heading without necessarily needing to add another edit yet. I often times "prime" an article first by adding these spaces, and then it is easier for me to read, and then I make the appropriate edits (of a typo, grammatical or other "gnome-like" fix). Another editor took issue with this, and thus a RfC was born. The conclusion of that RfC suggested for a conversation to take place here, in this talk page, with this guidance, Editors are invited to discuss how to phrase an appropriate edit to MOS:ACCESS that would explain the benefits of leaving a white line after headings for visually impaired people, and also the drawbacks for small-screen users. When the phrasing is agreed, the appropriate edit may be made.. Let the "discussion" commence now. . ♥Th78blue (talk)♥ 13:02, 31 March 2022 (UTC)

As can be seen in the talk page, before I learned how to formally "close" an RfC, I went ahead and made the edits that I felt were appropriate to the Wikipedia:Manual of Style/Accessibility page, but then I was (rightfully) scolded because I am not uninvolved, and I also had not properly closed the RfC yet. Now that it is closed (see link above), I want to see about discussing the sort of edit that can be made so that these space insertion edits could be made without being reverted, but also so that we take into consideration editors with the small screen issue raised by S Marshall in his closing comments. ♥Th78blue (talk)♥ 13:06, 31 March 2022 (UTC)

For anyone concerned, the guidance has now been updated. Zindor (talk) 00:18, 10 April 2022 (UTC)

Discussion at Talk:Takuya Nagase § Bundling citations

 You are invited to join the discussion at Talk:Takuya Nagase § Bundling citations. Marchjuly (talk) 15:10, 30 April 2022 (UTC)

WP:LISTGAP workaround, please

As written, Wikipedia:LISTGAP offers no way to break a long bulleted paragraph into two separate paragraphs (with the second one unbulleted). Is there a way to do this? If not, is there some other good strategy for dealing with a "wall of text" bullet item? - Butwhatdoiknow (talk) 16:52, 8 May 2022 (UTC)

• @Butwhatdoiknow: Use {{pb}}.
  Like this. --Redrose64 🌹 (talk) 21:57, 8 May 2022 (UTC)

  Thank you! I've edited the article so others may benefit from your knowledge. - Butwhatdoiknow (talk) 22:35, 8 May 2022 (UTC)

User:Redrose64, your most recent edit cites to wp:LISTGAP, which does not discuss "*:" vs. "::". That discussion is at MOS:INDENTMIX. Should we add text to LISTGAP to point to the INDENTMIX discussion (similar to this edit)?. - Butwhatdoiknow (talk) 20:08, 9 May 2022 (UTC)

Personally, I'd suggest linking directly to the appropriate section of this manual of style page in the edit summary. isaacl (talk) 21:08, 9 May 2022 (UTC)

When I created WP:LISTGAP several years ago, the present destination of MOS:INDENTMIX is precisely where it went. It's been diverted since then. --Redrose64 🌹 (talk) 23:04, 9 May 2022 (UTC)

Template:Information styling

Page watchers may be interested in Template talk:Information#General style of template (and use of mbox class). Please leave any comments there. Izno (talk) 03:51, 18 May 2022 (UTC)

2023 FIFA Women's World Cup qualification

File:2023 fifa womens qualification.jpg

I was checking this page on my phone, through the app, after the iPhone decided it was late enough to go to night vision--with the black background. The long and short of it, accessibility is gone--in 2023_FIFA_Women's_World_Cup_qualification#Knockout_stage, the scores seem to be white numbers on a white background; in 2023_FIFA_Women's_World_Cup_qualification#Knockout_stage, "Played" and "points" are white against a light-green and light-blue background, and are practically illegible. I'm already doubtful about whether the page fulfills MOS:COLOR in terms of contrast on my laptop, but what's happening on my phone is just unacceptable. Where is the problem? In the switch made by the phone for night vision, or with our colors--or both? Drmies (talk) 02:47, 15 July 2022 (UTC)

I've attempted to make a fix for this by defining a text color when we hardcode a background color as we do here. hopefully that will work, but it's going to take a while before we can verify in the app if that works or not. —TheDJ (talk • contribs) 14:27, 15 July 2022 (UTC)

User:TheDJ, thanks--I'll try to remember to check tonight. Drmies (talk) 14:41, 15 July 2022 (UTC)

From * to :

The following is said to be incorrect

* Support. I like this idea. —User:Example 
:* Question: What do you like about it? —User:Example2

What about this

:Here is a list of people I know:
:* John 
:* Peter —User1 
:: @User1, Why do you give this list? —User2

The logic is that User2 wants to reply to the entire comment of User1, not only to the last item in the list, which will be the case in

:Here is a list of people I know:
:* John 
:* Peter —User1 
:*: @User1, Why do you give this list? —User2

nor does he want to stay at the same level of indentation as the previous comment to which he replies as in

:Here is a list of people I know:
:* John 
:* Peter —User1 
:@User1, Why do you give this list? —User2

By the way, I know that the problem would be avoided if User1 would sign outside the list as in

:Here is a list of people I know:
:* John 
:* Peter 
:—User1 
:: @User1, Why do you give this list? —User2

However, it is very common that a list ends with a sublist.
If passing from * to : is a problem, a simple solution would be to add an intermediary item as in

:Here is a list of people I know:
:* John 
:* Peter —User1
: 
:: @User1, Why do you give this list? —User2

However, I really want to know if it is necessary to add this intermediary item to avoid passing directly from * to : . I suspect that the first example given is only incorrect because the machine would not understand that the item :* is a question about the previous item *. Therefore, it may be the case that passing from :* to :: is correct if the intention is not to reply to the previous item :*, but to reply to the overall item :. Dominic Mayers (talk) 12:34, 18 July 2022 (UTC)

I move the signature (as in your penultimate example) whenever I encounter this. Signing on a different level from the first paragraph of the comment leads not only to the problem you've raised but to unnecessarily wide indentation and the first paragraph(s) looking indistinguishable from unsigned comments, and should thus be prohibited. Nardog (talk) 13:33, 18 July 2022 (UTC)

Yes, it's not very logical to sign the last item of a list (as, unfortunately, often people do) instead of signing the entire comment that includes the list. I agree. But, it does not answer the technical question. Would the machine understand that

:Here is a list of people I know:
:* John 
:* Peter —User1
:: @User1, Why do you give this list? —User2

is the same semantically as this

:Here is a list of people I know:
:* John 
:* Peter —User1
: 
:: @User1, Why do you give this list? —User2

I know, in both cases, the signature is not well placed, but it's a different question. Dominic Mayers (talk) 14:00, 18 July 2022 (UTC)

Yes, it would understand that those two examples mean the same thing semantically. Graham87 14:34, 18 July 2022 (UTC)

Module:RoundN background colors

A discussion was started at Module talk:RoundN § Medal colors for gold/silver/bronze, aiming to change the module's background colors in favor of more accessible ones. Please, join us in it, as we lack experience in the subject. CLalgo (talk) 19:30, 26 July 2022 (UTC)

Have I got this right?

All,

A bit uncertain whether I'm doing this right. For the table at Los Angeles Chargers#Pro Football Hall of Famers will it work correctly for the screen reader as I have it, or would the phrase "San Diego / Los Angeles Chargers Hall of Famers" be read out twice in a row? Thanks in advance for any assistance. Harper J. Cole (talk) 23:48, 26 July 2022 (UTC)

Yeah that text is read out twice by a screen reader. Graham87 03:18, 27 July 2022 (UTC)

Thanks, I'll have to tweak it a bit. Harper J. Cole (talk) 17:43, 27 July 2022 (UTC)

Question on use of Template:Lang in section headings

See the documentation for {{anchor}} and MOS:HEADINGS for why this is an issue. As I just learned, {{subst:lang}} does not really work, but at the same time leaving untagged non-English content in section headings creates an accessibility issue. While rewording to avoid the non-English content may work in many cases, the subsections in articles like Spanish personal pronouns#Regional variation really should be tagged. I'm wondering if there's some guidance available, and if so, whether this MOS page should link to it in some manner. Thanks in advance! 69.174.144.79 (talk) 17:02, 28 July 2022 (UTC)

Images inside lists

Is it still true that embedding an image inside a list introduces a break, separating the single list into two lists? If so, should the MOS say not to do this? Example:

• First item followed by image

  

  Caption text

• Second item

Looking at the html it seems this may have been fixed? GA-RT-22 (talk) 15:05, 2 August 2022 (UTC)

@GA-RT-22: Your example places the image inside the first list item, which is permitted, although the alt text and caption will be read out following the textual part of the first list item and before the second list item is announced, so it's best to ensure that the image is directly relevant to that particular list item. A better form might be to place the image at the start of the list item, but still inside it:

Markup	Renders as
* [[File:Westminstpalace.jpg|thumb|upright=.5|alt=Alt text|Caption text]] First item preceded by image * Second item	Caption text First item preceded by image Second item

This follows the advice to place images before the text that refers to them. However, back to the point. The advice to which you refer concerns markup like this:

Markup	Renders as
* First item followed by image [[File:Westminstpalace.jpg|thumb|upright=.5|alt=Alt text|Caption text]] * Second item	First item followed by image Caption text Second item

This is two separate one-item lists with an image between. Apart from having separate lists, it is not clear whether the image relates to the first item or to the "second" item. --Redrose64 🌹 (talk) 23:11, 2 August 2022 (UTC)

Bolding Key Information in Articles

I've noticed a lack of thought when it comes to people who have comprehension and reading issues as of late in most articles, including newer ones, if the goal of Wikipedia is to help the general public learn about most of the time quite wordy information than should we not be bolding key words in articles? Sauriazoicillus (talk) 01:18, 8 August 2022 (UTC)

MOS:BOLD. Moxy- 01:21, 8 August 2022 (UTC)

Yes I am aware of the rules around bolding, I'm more asking it to be considered that key words should be allowed to be bolded in articles for accessibility purposes. Sauriazoicillus (talk) 02:59, 8 August 2022 (UTC)

It doesn't seem practical to do so, even were it to be permitted. Yes, wordiness can be a problem, but English Wikipedia is not intended to be Simple Wikipedia, especially as that already exists. BilCat (talk) 03:14, 8 August 2022 (UTC)

How would we determine which are the key words are in, say, Black Christian Siriano gown of Billy Porter? --Redrose64 🌹 (talk) 20:18, 8 August 2022 (UTC)

That's a can of worms no one should consider opening. GenQuest ^"scribble" 02:13, 9 August 2022 (UTC)

Maybe, but it was TFA yesterday (which is why I chose it), so will have had plenty of recent visits, including visits by people for whom accessibility is of great concern. --Redrose64 🌹 (talk) 12:32, 9 August 2022 (UTC)

Some types of list doesn't work

In buryat wikipedia horizontal lists doesn't work as intented and unbulleted lists are with bullets. What is the problem? 66.181.187.130 (talk) 16:53, 10 August 2022 (UTC)

Contrast in images

The section of this page covering colour and contrast seems to be primarily focused on text and data tables, but it seems to me that this is equally relevant to images. An image intended to illustrate an article should ideally have good contrast for visually-impaired and colourblind readers just as it should have good alt text for blind readers. A picture of a red phone box in front of a field of green grass would be an archetypal example of an image with this sort of problem where the issue may not be intuitively apparent to the majority of editors. I am unsure what amendments would be warranted here, if any at all, but a plainly worded statement on the matter could be helpful. HumanBodyPiloter5 (talk) 17:33, 14 August 2022 (UTC)

How can I test that my image alt text additions are working for blind users?

Moved from WP:Help desk § How can I test that my image alt text additions are working for blind users?

 Courtesy link: List of French monarchs

In this question at Help desk, I asked about testing alt text. This is probably a better venue for that question. Moxy suggested dispenser's Altviewer, which seems to work. Wondered what solutions you use? Thanks, Mathglot (talk) 01:45, 19 August 2022 (UTC)

Question: why would you want to see alt text without the need for a viewer/reader? Just wondering. Regards, GenQuest ^"scribble" 01:49, 19 August 2022 (UTC)

For testing. After I added the alt text in the wikicode, I couldn't tell if I got the syntax right or not; maybe it's not working for blind users either, so I was looking for how others test their alt text. One solution I read is that IE displays it; that could be a solution for some. Having it show up in some other reader is fine, and Moxy's solution works; a lot of times, there are multiple solutions, some better (or at least different) than others, and I wondered if there's one that is generally preferred, or if there are many solutions, or what. Perhaps it's like choosing an editor or a browser; I happen to think Vivaldi is the best browser, but such things are a matter of preference. Mathglot (talk) 02:04, 19 August 2022 (UTC)

What I do when testing accessibility is open the site in Lynx, a terminal browser. Because it runs on the terminal and cannot show images, it shows the alt text instead. weeklyd3 (block | talk | contributions) 03:02, 19 August 2022 (UTC)

The navigation popups gadget shows the alt text, along with much other detail, whenever you hover over an image. -- John of Reading (talk) 07:34, 19 August 2022 (UTC)

John of Reading, tried it out, and that solution works for me. Thank you! Mathglot (talk) 20:49, 19 August 2022 (UTC)

Does bold wiki-markup matter as far as placement?

I had brought this up elsewhere and I wanted to make sure there were no accessibility issues. I came across some bold markup that looks strange but seems to work fine visually. I have no idea if it causes problems with JAWS or other aids for sight-challenged and there seems to be no wikipedia rules on where you should or shouldn't place bold markup. Two ways of formatting bold in some articles is:

• {{flagicon|TUN}} '''[[Ons Jabeur]]''', which shows Ons Jabeur.
• '''{{flagicon|TUN}} [[Ons Jabeur]]''', which shows Ons Jabeur.

Both styles are prevalent throughout Wikipedia. Both give the same visual display on my laptop... the flagicon does not get visually bolded. Does using the bold markup before the flagicon template cause any issues or weirdness with screen readers, etc? Thanks. Fyunck(click) (talk) 08:56, 8 September 2022 (UTC)

As it says in the text section of the accessibility guideline, most screen readers won't even indicate things like bold/italics by default so it doesn't matter for screen reader users where the bolding is placed. Graham87 15:34, 8 September 2022 (UTC)

Just double checking, thanks. Fyunck(click) (talk) 19:33, 8 September 2022 (UTC)

Blank lines in bulleted list with {{sp}}?

Is it legitimate to introduce blank lines in the displayed list by using the {{sp}} spacing template? E.g.

* A longish entry
{{sp}}
* Another entry...

I would have thought not but it is done in the current edit of Mormon abuse cases#Selected LDS Church cases.

Best wishes, Pol098 (talk) 19:50, 8 September 2022 (UTC)

You're correct; it's not. I'll remove them. Graham87 02:43, 9 September 2022 (UTC)

If anyone reading this discussion wants to add blank lines in a displayed list, I think a legitimate way to is to append <br><br>to the end of each entry:

* A longish entry<br><br>
* Another entry<br><br>...

I'm not an expert, so hope this will be corrected if wrong. Best wishes, Pol098 (talk) 12:12, 9 September 2022 (UTC)

Indeed, something to that effect works. Graham87 14:46, 9 September 2022 (UTC)