Template talk:CBB yearly record start

message: I tried to use this template in rivalry mode as the example shows, but I do not get the proper columns with rivalryteam1 and rivalryteam2. Instead, the columns are season, team, and overall. For instance:

just shows the regular CBB start columns instead of the custom columns specified in the rivalryteam fields. However, the CFB version of this template works in Blue Key Victory Bell, for instance. Arbor to SJ (talk) 07:59, 26 September 2014 (UTC)
replies: text: , , any help? Arbor to SJ (talk) 07:54, 29 September 2014 (UTC)
replies: text: I don't think that was ever actually included in the CBB template - that looks like something that was just copied and pasted from the CFB description text and never removed for this specific template.  There's really no need to add it, either - the CFB template works fine, it just has a different name for the page. --fuzzy510 (talk) 08:02, 29 September 2014 (UTC)
thread_title:  Rivalry mode not working 

message: Please see Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Proper_table_captions_and_summaries.  for visibility. ―Justin (koavf)❤T☮C☺M☯ 19:53, 2 February 2020 (UTC)
replies: text: Take a look at examples like Ralph Jones, Phog Allen, Walter E. Marks, and you can see the problems we will have with included static captions, particularly their redundancy with the section headings. Jweiss11 (talk) 22:43, 2 February 2020 (UTC)
replies: text: , What do you propose as a solution? ―Justin (koavf)❤T☮C☺M☯ 22:44, 2 February 2020 (UTC)
replies: text: Don't have captions and make an exception to this rigid style point, which didn't consider such applications. Jweiss11 (talk) 22:46, 2 February 2020 (UTC)
replies: text: , This is not a style point: accessibility is not an afterthought for the aesthetic convenience of those of us who are able-bodied or neurotypical, etc. It's a requirement to meet the needs of those who do not have the same capabilities to process information. Please also see :m:Accessibility, :mw:Accessibility, :foundationSite:accessibility-statement/. We cannot forgo being accessible on high-priority, low-effort accessibility guidelines because they are misconstrued as stylistic. Again, happy to entertain other options. E.g. a field for inserting custom caption text and a default fallback that reads "Coaching statistics" if nothing is provided. ―Justin (koavf)❤T☮C☺M☯ 22:52, 2 February 2020 (UTC)
replies: text: Well, it certainly affects style and layout. I'm going to open a discussion about this on a related WikProject talk page a little bit later. Thanks, Jweiss11 (talk) 22:54, 2 February 2020 (UTC)
replies: text: , Of course it does affect those things. Style issues are less important than accessibility ones. We need to have accessible content, even if it's not as desirable to look at for those of us who have vision. ―Justin (koavf)❤T☮C☺M☯ 22:57, 2 February 2020 (UTC)
replies: text: Can you explain how a table heading makes this sort of content more accessible for a blind person? Jweiss11 (talk) 22:59, 2 February 2020 (UTC)
replies: text:  I'm having a similar conversation on the user's talk page. Eagles 24/7 (C) 23:05, 2 February 2020 (UTC)

text: , Captions in tables allow screen reading software to announce what the table is and means before rattling off what is in individual cells. This allows someone using this software to determine quickly what he is hearing and whether or not it's worth his time to listen. ―Justin (koavf)❤T☮C☺M☯ 23:13, 2 February 2020 (UTC)
replies: text: Koavf, wouldn’t a section heading accomplish the same thing? Jweiss11 (talk) 00:14, 3 February 2020 (UTC)
replies: text: , please answer this question. Thanks, Jweiss11 (talk) 05:21, 3 February 2020 (UTC)
replies: text: , No, it would not accomplish the same thing. Level three headers are semantically different than table captions and software engages or uses them differently—e.g. the former may make the skeleton of an OPML outline or be used for a search engine to index certain pages and anchors within them, whereas the latter may be read aloud by a screen reader and is used by persons browsing with them to determine if they want to listen to the rest of the tablular data, etc. I don't mean to talk down to anyone here but these things are different for a reason and none of them are stylistic. Accessibility is not negotiable. ―Justin (koavf)❤T☮C☺M☯ 05:31, 3 February 2020 (UTC)
replies: text: Koavf, this accessibility measure is indeed having a negative stylistic impact on the articles in questions, for the vast majority of users who read them. We just need to alert screen readers that there is table, correct? Couldn't we have some sort of field that tells the screen readers that's there a table here (and perhaps gives them a brief description of content of the table), but doesn't render viewable (and redundant) text for those users who are reading the articles? Jweiss11 (talk) 05:38, 3 February 2020 (UTC)
replies: text: I have reverted the caption "Coaching statistics" per the documentation and the usage at Tennessee Lady Volunteers basketball , where there are no coaches listed. Please continue to discuss (before implementing a change to the template) to find a resolution that works for accessibility and accuracy. – Jonesey95 (talk) 16:48, 3 February 2020 (UTC)

text: This still doesn't work as it adds redundant, meaningless clutter to the table. We need to step back and come up with a far more fundamental, universal solution here that can be applied uniformly to all tables like this across the whole encyclopedia without comprising presentation. Jweiss11 (talk) 20:24, 5 April 2020 (UTC)
replies: text: , What is "compromised" here and you still seem to fundamentally misunderstand that your minor inconvenience with "clutter" as someone who has functioning eyes does not trump the accessibility of those who do not. ―Justin (koavf)❤T☮C☺M☯ 20:32, 5 April 2020 (UTC)
replies: text: Koavf, can you explain why we can't put code in these tables to alert the text readers that they are running into a table without actually displaying any text for the conventional rendering? Jweiss11 (talk) 20:35, 5 April 2020 (UTC)
replies: text: , This is petty vandalism. I guess you think that accessibility is a joke but I'm glad that others don't. What "code" are you talking about? What is "compromised"? If you refuse to understand the very simple accessibility guidelines that say that table captions are required for accessibility and are very easy to implement, I don't know how to help you. ―Justin (koavf)❤T☮C☺M☯ 20:46, 5 April 2020 (UTC)
replies: text: I'm happy to discuss more accurate captions here with you in good faith but that was not a good faith action--it was vandalism and was reported as such. ―Justin (koavf)❤T☮C☺M☯ 20:51, 5 April 2020 (UTC)
replies: text: It wasn't vandalism. I was making a point about the absurdity and stubbornness of your approach which has been obstructive.  I don't think that accessibility is joke.  But we should not compromise the conventional display for the sake of accessibility, when we can accomplish what is needed in another manner.  The "code" I am talking about is code that would give the text reader for the blind proper instructions for dealing with tables without altering the display for readers who can see and read the conventional display. Jweiss11 (talk) 21:27, 5 April 2020 (UTC)
replies: text: , That code is table captions. Template editors should not revert without careful consideration but you just reverted because of "clutter" (it's not) and then had a dumb stunt. It's bad faith and unacceptable. I don't know why you're acting otherwise. ―Justin (koavf)❤T☮C☺M☯ 21:31, 5 April 2020 (UTC)
replies: text: We need other code then to make this work for all scenarios. My initial revert was indeed carefully considered and a product of lengthy previous discussion. Jweiss11 (talk) 21:34, 5 April 2020 (UTC)

text: I've asked this same question multiple times, can we service the accessibility readers without compromising the standard display? Please see the RFC below. Jweiss11 (talk) 00:47, 6 April 2020 (UTC)

text: , Remove the section headings? I'm open to suggestions that are anything other than "Let's make things let's accessible for my mild convenience". Far better a little redundancy or having to see three words two times than to make an inaccessible page. ―Justin (koavf)❤T☮C☺M☯ 00:59, 6 April 2020 (UTC)
replies: text:  I meant more along the lines of invisible text. In other programming languages I have used, there are different types of comments/text that are displayed depending on the interface used. Obviously, this is slightly different as the programming needs to be more accepted than what I am used to, so I don't know the answer here. The section headers are more useful as notation can be added between the tables and headers (see the Colts linked above pointing out that only the last five seasons are linked, etc) whereas the caption cannot do that without breaking the table format. It just seems that as you implement these changes across the multiple projects, you get a lot of push back. An invisible accessibility-only text would fix tons of these problems. Yosemiter (talk) 03:25, 6 April 2020 (UTC)
replies: text: , If an individual doesn't want to see it, he can edit his CSS to mark captions as display:none. I don't think that making captions invisible by default is wise. ―Justin (koavf)❤T☮C☺M☯ 04:04, 6 April 2020 (UTC)
replies: text:  I don't think you understand my proposal, it would only be invisible to those who don't need it. Using a reader program would read it just fine. Even making the text of the caption the same color as the background would fix the blind assist issue. Those reading with eyes won't see it, those using assistance programs would still have the words read to them. (Assuming I understand how the accessibility programs actually interpret data. This isn't for the folks who can read the section headers, so invisible text would have no affect on those who cannot read it even if it was visible.) It removes visible duplication while also maintaining the accessibility for the visually impaired. Yosemiter (talk) 04:17, 6 April 2020 (UTC)
replies: text: , No, I don't think I do understand. I don't think that including apparently blank lines that actually have hidden text is a solution to any problems. For that matter, I don't see a problem with seeing "Year-by-year statistics" or "Annual sales chart performance" at the top of a table as a problem. In fact, I think it's an improvement. Do you know of any instances of any other web pages that use the solution that your suggesting? Maybe seeing it live in the wild will help me understand how this is a good idea. ―Justin (koavf)❤T☮C☺M☯ 04:21, 6 April 2020 (UTC)
replies: text: Koavf you don't see a problem with redundant, generic captions like "Statistics overview". That could describe virtually any table that contains numerical figures? How does that help? Jweiss11 (talk) 05:34, 6 April 2020 (UTC)
replies: text: , No, I don't. It helps because it says what the table is about. If you have a better suggestion for what a caption would be, feel free to propose it. (And now, "Hey! Here's a table!" does not help.) All tables should have captions and summaries. Why are you fighting me on this? Why is making tables inaccessible he hill you want to die on? ―Justin (koavf)❤T☮C☺M☯ 06:24, 6 April 2020 (UTC)
replies: text: You're assuming a false premise about the hill I want to die on here. How about "Table data"? It's more accurate and flexible than "Statistics overview" despite being roughly as useless and redundant. You still haven't explained how a generic captain, one that could be otherwise implied tacitly, makes the table more accessible. Jweiss11 (talk) 06:33, 6 April 2020 (UTC)
replies: text: , You've remained willfully ignorant about what table captions are. I have explained this several times and yet you seem to have no idea what their function is and how to use them which is something that I don't think I can remedy. I've referred you to the appropriate part of the accessibility guidelines and recommended that you do some reading on W3C and ARIA documentation if you really want to know but it seems to me that you don't and want to keep on bickering about how helping the blind doesn't really matter because you don't want to see two or three words that you feel like waste your time. I don't think that "Table data" is a better caption: please explain how that would better explain what is in the table. Please explain to me when you think that table captions and best accessibility practices should be ignored. ―Justin (koavf)❤T☮C☺M☯ 10:03, 6 April 2020 (UTC)
replies: text: Because "table" is a more accurate description than "statistics". What kind of statistics and in what form? And "data" is more apt than "overview". Overview of what? This is the first I'm seeing you use the acronyms "W3C" and "ARIA". Can you define those?  Most importantly can you explain the following? How is a machine reading "Head coaching record...College...Statistics overview...Season...Team...Conference...Standing..." more helpful to a blind person than that machine reading "Head coaching record...College...Season...Team...Conference...Standing...". Jweiss11 (talk) 11:57, 6 April 2020 (UTC)
replies: text: , W3C and WAI-ARIA. No, I cannot. I'm also going to start ignoring your requests since you ignored mine. If you want more information from me (that you could easily find yourself with a search engine), you'll have to actually answer the requests I made in my last post first. ―Justin (koavf)❤T☮C☺M☯ 20:24, 6 April 2020 (UTC)

text: Koavf, your proposed personal CSS solution doesn't work, because there are some tables, particularly static one-off tables, where the caption tag indeeds provides a useful introduction, for example Template:2019–20 coronavirus pandemic data. This is, however, not the case regarding this template, CBB yearly record start, which is used to dynamically render thousands of different tables in an array of slightly different contexts with local section headings providing the proper introduction to the tables in each instance. Jweiss11 (talk) 12:14, 6 April 2020 (UTC)

text: , a local discussion like the one you linked to above is not widespread opposition. It is a local collection of editors on a particular topic or subject opposing the MOS without providing a workaround solution. Widespread opposition would have been a discussion at the MOS with people saying its not required etc. As a community we can't have gatherings of editors around a specific topic creating local consensus to ignore the MOS when the MOS applies to all topics and subjects. Anyway there are some useful suggestions below by ReXXs. → Lil-℧niquԐ1 - (Talk) - 09:09, 7 April 2020 (UTC)

text: I believe that's a fair compromise. Eagles 24/7 (C) 19:29, 6 April 2020 (UTC)

text: Something like "Head coaching record" or "Head coaching record table" would also be far more useful for readers using a screen reader. Jweiss11 (talk) 19:04, 30 April 2020 (UTC)
thread_title:  Captions are necessary 

message: This discussion has just been linked from Wikipedia_talk:WikiProject_College_Basketball#Template:CBB_yearly_record_start, which is a very selective choice. A similarly justifiable (or not justifiable) action would have been a notification of WikiProject Accessibility, which has not happened yet. The discussion is currently linked from WP:ANI, but I'm unsure how helpful this is and which effect it has on the discussion. To ensure that canvassing is not an issue, please convert this discussion to a neutral RfC and gain wider participation. ~ ToBeFree (talk) 22:13, 5 April 2020 (UTC)
replies: text: Koavf, your proposed personal CSS solution doesn't work, because there are some tables, particularly static one-off tables, where the caption tag indeeds provides a useful introduction, for example Template:2019–20 coronavirus pandemic data. This is, however, not the case regarding this template, CBB yearly record start, which is used to dynamically render thousands of different tables in an array of slightly different contexts with local section headings providing the proper introduction to the tables in each instance. Jweiss11 (talk) 12:14, 6 April 2020 (UTC)

text: , a local discussion like the one you linked to above is not widespread opposition. It is a local collection of editors on a particular topic or subject opposing the MOS without providing a workaround solution. Widespread opposition would have been a discussion at the MOS with people saying its not required etc. As a community we can't have gatherings of editors around a specific topic creating local consensus to ignore the MOS when the MOS applies to all topics and subjects. Anyway there are some useful suggestions below by ReXXs. → Lil-℧niquԐ1 - (Talk) - 09:09, 7 April 2020 (UTC)
thread_title:  RFC request 

message: 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  says, 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. 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 would discourage the practice, but not forbid it.
Because a template can be used on any relevant article now or in the future, and the placement of a table immediately below a heading can change in any article, it's not sensible to assume that the conditions for begrudgingly omitting a caption will always be met.
Therefore I suggest that the solution should be to have a default caption for this template, but to add a parameter allowing it to be changed on a per article basis where required. That should give an editor at the article level the opportunity to have no heading (test for the caption being equal to the word "none", for example) if that is felt to be justifiable in a particular case. --RexxS (talk) 19:20, 6 April 2020 (UTC)
replies: text: I believe that's a fair compromise. Eagles 24/7 (C) 19:29, 6 April 2020 (UTC)
thread_title:  Suggestion 

message: I'd like to prose wrapping the newly-added table caption of "Statistics overview" with Template:Sronly so that it renders only for screen readers. In conventional visual renderings, the caption is redundant, generic, and unhelpful. Jweiss11 (talk) 18:59, 30 April 2020 (UTC)
replies: text: Something like "Head coaching record" or "Head coaching record table" would also be far more useful for readers using a screen reader. Jweiss11 (talk) 19:04, 30 April 2020 (UTC)
thread_title: Wrap table caption with Template:Sronly