Template talk:CBB yearly record start

Rivalry mode not working

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: {{CBB yearly record start | type = rivalry | rivalryteam1 = Ball State | rivalryteam2 = Indiana State}}

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)[reply]

Fuzzy510, AGK, any help? Arbor to SJ (talk) 07:54, 29 September 2014 (UTC)[reply]

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)[reply]

Captions are necessary

Please see Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Proper_table_captions_and_summaries. @Jweiss11: for visibility. ―Justin (koavf)❤T☮C☺M☯ 19:53, 2 February 2020 (UTC)[reply]

@Koavf: 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)[reply]

Jweiss11, What do you propose as a solution? ―Justin (koavf)❤T☮C☺M☯ 22:44, 2 February 2020 (UTC)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

@Jweiss11: I'm having a similar conversation on the user's talk page. Eagles 24/7 (C) 23:05, 2 February 2020 (UTC)[reply]

Jweiss11, 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)[reply]

Koavf, wouldn’t a section heading accomplish the same thing? Jweiss11 (talk) 00:14, 3 February 2020 (UTC)[reply]

@Koavf:, please answer this question. Thanks, Jweiss11 (talk) 05:21, 3 February 2020 (UTC)[reply]

Jweiss11, 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)[reply]

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)[reply]

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)[reply]

I've added a more generic caption. ―Justin (koavf)❤T☮C☺M☯ 19:57, 5 April 2020 (UTC)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

@Eagles247: You were the only other person who discussed the caption in the above discussion. What do you think of the one that I have now? Correct me if I'm wrong but we came to consensus on similar captions earlier. ―Justin (koavf)❤T☮C☺M☯ 21:08, 5 April 2020 (UTC)[reply]

Koavf While I understand the accessibility issues you are addressing, it does add repetitiveness in many articles. (I think I pointed this out on the Indianapolis Colts article with the Indianapolis Colts#Season-by-season record having a section called Statistics and records, a subsection titled Season-by-season record, and a table header of Indianapolis Colts season-by-season records.) So I wonder, is there a solution to the "clutter problem" where the table headers are read by the accessibility readers but does not physically display in the article, sort of like a hidden note? This could solve a great many issues. Yosemiter (talk) 00:44, 6 April 2020 (UTC)[reply]

@Yosemiter: 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)[reply]

Yosemiter, 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)[reply]

Koavf 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)[reply]

Yosemiter, 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)[reply]

Koavf 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)[reply]

Yosemiter, 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)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

Jweiss11, 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)[reply]

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)[reply]

Jweiss11, 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)[reply]

RFC request

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)[reply]

We could use some more input from the community regarding this template, and by extension several cousins like like Template:CFB Yearly Record Start, Template:CFB schedule, Template:CBB schedule start, and likely many more. These templates are all used to render tables of sports statistics and are generally used immediately following a section heading that introduces the content of the table. In an effort to meet requirements for accessibility, specifically those for screen readers for the blind, koavf has added a caption within this table to introduce its content. This has the unfortunate consequence of rendering a generic cluttering intro at the top of the table following a more specific intro garnered from the preceding section headings. See; Mike Krzyzewski#Head coaching record for an example. Jweiss11 (talk) 22:29, 5 April 2020 (UTC) Please see Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Proper_table_captions_and_summaries Table captions are high-priority and easy to implement for basic accessibility. There is no argument for not including them. If you don't like seeing them, feel free to edit your personal CSS to make the caption tag nodisplay. The mild inconvenience about seeing two or three words that you don't need to see far outweighs making the template accessible to others. ―Justin (koavf)❤T☮C☺M☯ 00:18, 6 April 2020 (UTC)[reply]

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)[reply]

What if we call the caption "Records table"? I believe that's neutral, applies to most instances of this template's usage, and is a better descriptor for this than "Statistics overview". Eagles 24/7 (C) 12:27, 6 April 2020 (UTC)[reply]
Better description, but still suffers from the redundant clutter problem. Jweiss11 (talk) 16:53, 6 April 2020 (UTC)[reply]
I've informed WT:WCAG. --Redrose64 🌹 (talk) 13:08, 6 April 2020 (UTC)[reply]
Support use of captions. Having been involved in some early adoption of the MOS on Accessibility I'd like to civilly and politely remind individuals what the caption for tables is for and how it helps disabled/partially sighted users. The MOS on accessibility addresses significant formatting and stylistic choices which make things difficult for partially sighted individuals and screen reading technology. Without the heading, screen reading technology will begin reading the table without any explanation for the reader. Now if you can see and have no trouble with sight, this isn't an issue. However, those who have sight issues won't necessarily understand the same way. The caption for tables is the same as captions for images, it summarises the content whereas page headings are for navigation. Table captions are therefore extremely useful if you put yourself in the mindset of such readers. Captions don't need to be complex e.g. A summary of yearly progress. Koavf is right - the MOS is to adhered to. Arguments about "it looking cluttered" or "it isn't required" don't combat the accessibility issues caused by excluding them. The consensus is in the MOS which is becoming more and more high profile around the world, and where disabled or hard of sight individuals are already disadvantaged there is no argument which justifies ignoring changes which make things more accessible. User Jweiss11 sites widespread opposition but I haven't seen this... Furthermore, these tables should also really use the ! scope="row" class for each row too whilst we're speaking about non-compliance. → Lil-℧niquԐ1 - (Talk) - 14:49, 6 April 2020 (UTC)[reply]
Lil-unique1, why can't we add a description for these tables that only renders for screen reading technology, so that it doesn't add redundancy for the conventional display while still servicing the accessibility concern? Jweiss11 (talk) 16:52, 6 April 2020 (UTC)[reply]
Jweiss11, Tables should have both captions and summaries (is this what you mean by "descriptions"?). Again, I refer you to the page above and W3C and ARIA guidelines. ―Justin (koavf)❤T☮C☺M☯ 20:26, 6 April 2020 (UTC)[reply]
Support, as a screen reader user, I agree with everything Lil-unique1| said. Additionally, with my screen reader JAWS, without the caption it tries to use the first column title for this purpose; I don't think "season" is a very good description for this table. Graham87 15:11, 6 April 2020 (UTC)[reply]
Graham87, can you describe your experience of consuming the table at Mike Krzyzewski#Head coaching record using your screen reader app? Jweiss11 (talk) 16:56, 6 April 2020 (UTC)[reply]
@Jweiss11: I press the quick navigation key "t" to get to it and JAWS says "Statistics overview" as it should. The table is fairly accessible. Graham87 01:41, 7 April 2020 (UTC)[reply]

Isn't the subheading "College" redundant even without the caption? Krzyzewski has only coached in college and this is the only subheader within "Head coaching record". Under my proposal his article would read "Head coaching record" → "Records table" → actual table. Eagles 24/7 (C) 17:06, 6 April 2020 (UTC)[reply]
No, because Krzyzewski has also been a head coach in international basketball, for which a record table should eventually be created. Compare with Bob Huggins, who has only been a head coach at the college level. Jweiss11 (talk) 17:10, 6 April 2020 (UTC)[reply]
Ralph Jones is an interesting example of someone who was a head coach of record of multiple sports each at multiples levels. Jweiss11 (talk) 17:13, 6 April 2020 (UTC)[reply]

Lil-unique1, per "widespread opposition", please see Template talk:Football squad start#Template-protected edit request on 1 February 2020, which also involved Penepi and S.A. Julio. Jweiss11 (talk) 17:44, 6 April 2020 (UTC)[reply]

@Jweiss11:, 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)[reply]

It's worth still seeking a consensus solution for this template. I hope my suggestion below might represent a step in that direction. However, this debate has highlighted the degree of uncertainty surrounding table captions. I have therefore instigated an RfC on the issue, and sought the broadest possible input at Wikipedia talk:Manual of Style/Accessibility #RfC on table captions. I know you may have debate fatigue by now, but I would still value your views on whether tables captions should effectively be expected to be present by default. --RexxS (talk) 22:05, 6 April 2020 (UTC)[reply]

Suggestion

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 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)[reply]

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

Support a visible caption that is descriptive and can be overridden. I would suggest also switching the default caption based on the |type= parameter, since that's already available. Not having a caption is an accessibility problem, and accessibility problems are barrier to our purpose. --AntiCompositeNumber (talk) 19:35, 6 April 2020 (UTC) (edit conflict × 2)[reply]
Support default caption language with an option to modify it but there should always be a table caption and it should never be "None" or "Null" or "See above" or anything that is not descriptive. If someone is going to come along and write something useless and antagonistic like "Heads up! This is a table!", that person should receive some kind of sanction for it. ―Justin (koavf)❤T☮C☺M☯ 20:29, 6 April 2020 (UTC)[reply]
Support captions by default captions are NOT optional. → Lil-℧niquԐ1 - (Talk) - 09:05, 7 April 2020 (UTC)[reply]

Wrap table caption with Template:Sronly

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)[reply]

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)[reply]

@Jweiss11: I didn't know Template:Screen reader-only existed. I support rendering the table caption only on screen readers. I also agree that "Head coaching record" or "Head coaching record table" would be more useful. ~WikiOriginal-9~ (talk) 20:20, 25 October 2024 (UTC)[reply]