Wikipedia talk:Manual of Style/Accessibility

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

Clarification on policy on column headers in the middle of tables

Many concert tour lists and articles contain headers in the middle of tables (Zoo TV Tour#Tour dates (FA), Rebel Heart Tour#Shows (GA), Not in This Lifetime... Tour#Tour dates (GA), etc. However, this is contrary to MOS:DTT#Avoiding column headers in the middle of the table, which includes: "Do not place column headers in the middle of a table to visually separate the table. Assistive technologies will get confused as they cannot know which previous headers still apply to parts of the table after the first one ... In most cases, the easier solution is to split the table into several sub-tables with explanatory sub-headings" with good and bad examples. MOS:DTT is not a policy nor a guideline. Should it only be considered optional? —Ojorojo (talk) 16:15, 28 September 2019 (UTC)

MOS:DTT contains examples of best practice, so it's not optional in the sense of "at an editor's whim". If there are good reasons why the table's organisation would benefit from having more than one column header in the table, then editors should not let MOS:DTT stop them from doing that, although they really should still add scope="col" to those headers as a help for screen readers. In the years since that advice was written, screen readers have evolved to cope with more complexities in tables, but we should nevertheless be doing our best to accommodate those who still use older versions. --RexxS (talk) 18:26, 28 September 2019 (UTC)

I see no good reason not to fix these cases. I might even argue that those aren't necessary to be represented in the table at all given that the locations are present already. (I would lean slightly to better practice 1 than 2 since the locations are implied by the locations of each of the tour locations.) --Izno (talk) 18:44, 28 September 2019 (UTC)

Thanks. I'll add a comment at WT:WikiProject Concerts and link this discussion. —Ojorojo (talk) 13:47, 29 September 2019 (UTC)

RexxS, Izno: While following MOS:ACCESS for discographies is advised during the featured list review process (that's how I learned of it), it hasn't caught on for good article nominations. I've brought it up at WT:GAN#WP:ACCESS concerns; maybe others' comments would help explain it. —Ojorojo (talk) 16:13, 6 February 2020 (UTC)

GA participants don't usually know much about ACCESS or most MoSes or editing guidelines, and then the GAs are held-up as paragons of correct formatting, ACCESS, MoS, and guidelines rather than the project decisions. Where may I comment? Walter Görlitz (talk) 17:50, 6 February 2020 (UTC)

@Walter Görlitz: I started it at WT:GAN#WP:ACCESS concerns. —Ojorojo (talk) 16:35, 7 February 2020 (UTC)

MathML

Please see my question about the accessibility of MathML, at Talk:MathML#Accessibility - I'm sure the requested answer there will be of use to this project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 9 January 2020 (UTC)

Likewise Talk:LaTeX#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 9 January 2020 (UTC)

Lotka–Volterra equations seems like a good test page for MathML; do you have a good test page for the LaTeX, Andy Mabbett? HLHJ (talk) 21:17, 1 February 2020 (UTC)

possible accessibility issue in "football" roster templates

Several years ago, a few editors raised an accessibility concern with accessibility in the template used to list football (or soccer if you prefer) player rosters at {{Football squad player}}. That listing is very compact, but the nationality is hidden and represented in the link and possibly a hover text. They proposed and created {{Football squad player2}}. It's less compact but does list the nation correctly. Both incorrectly link to the nation in violation of WP:OVERLINK. Football squad player2 is not now up for a deletion discussion: Wikipedia:Templates for discussion/Log/2020 February 1#Template:Football squad player2. Feel free to weigh-in there. Walter Görlitz (talk) 00:56, 2 February 2020 (UTC)

There is now an RfC on the format of the template here. Number 57 10:59, 17 February 2020 (UTC)

Since the RfC is discussing the accessibility of the proposed merged template, it may be of interest to members of this project. --RexxS (talk) 15:59, 17 February 2020 (UTC)

SMALLFONT problem

{{LSR}} is embedded into several other infobox templates. For instance in the infobox on Windows 10 the "Latest release" and "Latest preview" fields make calls to the template and with the small tags built into the original, break MOS:SMALLFONT. I left a comment on the template talk nearly three months ago with no follow-up and no change. See Category:Latest stable software release templates. Walter Görlitz (talk) 01:55, 20 February 2020 (UTC)

 Fixed. You can use an edit request template for a faster response. – Jonesey95 (talk) 02:24, 20 February 2020 (UTC)

Thanks. I wanted to gain consensus before using {{edit protected}}, but the anticipated push-back never materialized. Walter Görlitz (talk) 02:31, 20 February 2020 (UTC)

MOS:FONTSIZE has a strong consensus as part of accessibility, so there should not be any concerns. – Jonesey95 (talk) 03:58, 20 February 2020 (UTC)

I never try to push an external consensus. See the issues above at the football template for instance. Walter Görlitz (talk) 05:14, 20 February 2020 (UTC)

MediaWiki changes that affect accessibility

There are several changes to MediaWiki that will affect accessibility. Please see Wikipedia:Talk pages project#Other projects.

In particular:

1. The upcoming Reply tool should make it easier for people to reply (less scrolling through wikitext to find the right place).
2. The proposed signature requirements should make it easier to tell who posted a comment and prevent some messes.
3. The multi-line syntax thing should make WP:LISTGAP easier to handle (just wrap the mess in the new wikitext code, and it all becomes the same list item).

Please put that page on your watchlists, and ping me (here or there) with any information or requests you have. Whatamidoing (WMF) (talk) 18:56, 12 March 2020 (UTC)

WP:THREAD and MOS:LISTGAP suggest different advice

At WP:THREAD, the suggestion is to use colons (:). At MOS:LISTGAP, the examples for best practice use asterisk (*), though the intention here was to convey accessibility issues with mixing different types. This is a bit inconsistent. 84.250.17.211 (talk) 05:12, 18 March 2020 (UTC)

See also MOS:INDENTGAP, further down the page. The point is not that you can only use asterisks, or only use colons: the point is that you should not mix them at the same level. --Redrose64 🌹 (talk) 13:13, 18 March 2020 (UTC)

In reply to 84.250.17.211, I think that we don't have such a problem with normal threaded conversations that simply use colons alone. It's rare for someone to make the mistake of switching from using colons to using asterisks in those cases, whereas in "list-type" threads such as RfCs that use asterisks to delineate each separate !vote, you do find all too often that someone will make the mistake of replying to a comment by using two colons (::) to create an indent, which destroys the list sequence for screen reader users. It's for those sort of errors that we give the examples to help editors understand what should be done. We could simply duplicate the advice in MOS:LISTGAP, giving parallel examples that start with a colon, but I don't think there's any real need to do that. --RexxS (talk) 13:33, 18 March 2020 (UTC)

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)

RfC on table captions

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)

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)

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

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)

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)