Wikipedia talk:Manual of Style/Accessibility

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

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)

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)

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)

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)

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

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)

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)

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!