Template talk:SCOTUS-termlist-entry

Accessibility

I'm looking at this template and cannot find how it meets the requirement for WP:Accessibility--that is, that the cells when produce in a table do not identify in a non-color based fashion what a particular Justice's opinion was. I almost slapped a {{Accessibility dispute}} on one of the pages which this template is used on, but decided it might be better to poke here first. --Izno (talk) 17:33, 26 June 2015 (UTC)

This is the first time in the decade that these tables have been generated and maintained that I've seen this issue raised, though I have thought about it but haven't yet figured out an appropriate code update. So I'm open to suggestions on how to also add alt text to the table, but only so long as it doesn't alter or destroy the table's functionality. The visual information is the only way to concisely present the full range of information contained in the opinions column; it often takes the Court a whole text paragraph to lay it out who filed or joined what, while just using color and split cells it can be done in one row in these tables. Note I've also asked for more input at Wikipedia talk:WikiProject U.S. Supreme Court cases. postdlf (talk) 17:55, 26 June 2015 (UTC)

I think letter text of one to three letters for each of the colors would suffice (one could also use <span title=""></span> if you wanted around the letters in question to make it really obvious), since in most cases these tables are used on pages with the key (and the letters obviously added to the key). The problem is the use of 5 potential opinions that could be represented for any particular Justice, though it seems that given the example's McConnell v. Federal Election Commission that all or most of the 5 are used in the hard-to-represent cases. And I'm not sure how the numbers are being generated in that example either, so that's a second issue to deal with. --Izno (talk) 18:04, 26 June 2015 (UTC)

I'm not sure I understand what you're suggesting, but if it works I'd be happy to implement it throughout the code (which is ridiculously complex to accommodate ridiculous opinions like McConnell, as you've discovered). Could you sandbox a one row table example with what you're thinking of? postdlf (talk) 18:17, 26 June 2015 (UTC)

This might end up a sandbox project for me for Lua-ization (because I would like to work on this) since the template version looks disgusting.

For Faith v. Reason as per the example, considering only the justices and not the rest of the table:

Rehnquist	Stevens		O'Connor	Scalia	Kennedy		Souter	Thomas	Ginsburg	Breyer
JM	D1	JD2	JM	JM	JD1	D2	JM	JM	JM	M

Basically, my proposal is to output some text in addition to the colors. I happened to use text which makes sense in the domain in this case, but you could just as easily assign A, B, and C and have the key note this. Optionally included in my suggested change could be, as noted above, some variant of <span title="Joined Majority">JM</span> such that when hovered over, and for blind users, the title is read providing the meaning. Not sure if that's desirable though. --Izno (talk) 20:20, 26 June 2015 (UTC)

Putting more displayed text in the boxes will screw up the layout and clarity of the information, particularly where a justice takes multiple actions in the same case. The hover over text is more what I was thinking; is the span title tag really all it takes to include that? Do you know of a help page on that? I'll play around with that later. postdlf (talk) 20:28, 26 June 2015 (UTC)

I don't see how text screws up the layout aside from making the table run off the page; I don't agree with the assertion of clarity; as for the spans, they won't work without some content inside the cell. And yes, most viewable browsers work like that; I don't know if blind browsers do. --Izno (talk) 20:31, 26 June 2015 (UTC)

The layout requires the cells to be identical size, otherwise there's no uniformity between justices or between cases and the visual comparison goes out the window. And I don't think it's a small thing to bloat the width out off the screen, as that just makes it harder to view for everyone compared to whatever small segment has an issue with the color. As I said, I've been working on developing and improving these for the last ten years, and the code has also been changed over that time. We'll figure it out eventually so we can have our cake and eat it too. postdlf (talk) 20:51, 26 June 2015 (UTC)

Another option, at least until we figure out a more graceful code-based alt text option, might just be to add another column to the far right of the table that repeats the opinion info in text form. That would be easy to implement in the template code, and shunting it off to the side would keep it from undermining anything the table currently does. But that would be quite the kludge, and it would take a lot of work to fully implement it in all these lists, which even without color still function as basic term opinion lists. Anyway, let's wait for more input. There are at least a couple SCOTUS project members who are better at template code than I am and so might have some ideas. postdlf (talk) 21:41, 26 June 2015 (UTC)

Another thought... How does collapsed text affect accessibility? Will a text reader for the blind read text even if it's collapsed by default? postdlf (talk) 01:45, 27 June 2015 (UTC)

Screen readers will read collapsed text, but they won't easily be able to read text that requires hovering to access it. Graham87 06:12, 27 June 2015 (UTC)

A real current example from 2009 term opinions of the Supreme Court of the United States:

#	Case name and citation	Argued	Decided	Roberts	Stevens	Scalia	Kennedy	Thomas	Ginsburg	Breyer	Alito	Sotomayor
19	Citizens United v. Federal Election Comm'n, 558 U.S. ___	September 9, 2009	January 21, 2010	1	* 1	2		* 2* 2	* 1	* 1	1 2	* 1
#	Case name and citation	Argued	Decided	Roberts	Stevens	Scalia	Kennedy	Thomas	Ginsburg	Breyer	Alito	Sotomayor

A version using Template:SCOTUS-termlist-entry/sandbox instead so that we can play around with the formatting.

#	Case name and citation	Argued	Decided	Roberts	Stevens	Scalia	Kennedy	Thomas	Ginsburg	Breyer	Alito	Sotomayor
19	Citizens United v. Federal Election Comm'n, 558 U.S. ___	September 9, 2009	January 21, 2010	1	* 1	2		* 2* 2	* 1	* 1	1 2	* 1
#	Case name and citation	Argued	Decided	Roberts	Stevens	Scalia	Kennedy	Thomas	Ginsburg	Breyer	Alito	Sotomayor

I don't have a good solution off-hand. And now having looked at the code powering Template:SCOTUS-termlist-entrysupport, I'm a bit terrified. :P --MZMcBride (talk) 14:09, 27 June 2015 (UTC)

Terrified in a good way, or...? My goal in developing the code has been to make the user-end of the template as simple as possible while enabling it to handle the most complicated opinion/vote combos possible. Consequently, the entrysupport template has to repeat all the possible permutations for every justice slot (and every subslot where a justice takes multiple actions). If you can think of a way of streamlining that code while retaining all of that functionality, you get a barnstar. postdlf (talk) 15:17, 27 June 2015 (UTC)

Definitely a bad way. The colors at least aren't all that scary; the trivial change there would be to use switch statements. I think a good chunk of the rest of the template could also be resolved in that fashion. That's why I was interested in trying to Lua-ize it. --Izno (talk) 19:16, 27 June 2015 (UTC)

Template:SCOTUS-termlist-entrysupport is currently using ParserFunctions (#if, etc.), when it should probably be using Scribunto/Lua instead (basically echoing what Izno wrote directly above this comment). The real pain is that reading the code below Template:SCOTUS-termlist-entrysupport is currently pretty rough, and implementing any improvements requires both reading and understanding the code. And unfortunately my Lua skills are probably about as good as yours at the moment, so I'm not sure how much help I can be.

In general, the table is quite wide on my screen (with all nine Justices + metadata) and probably doesn't scale down to a mobile-size screen very well either, so I'm wondering if there's a better way to display this data. In my dream world, we could find a way to make the final output less wide when necessary and find an alternative to the colors to indicate the opinion type. But this is a relatively challenging design problem, I think, so I have few good answers right now. --MZMcBride (talk) 00:57, 28 June 2015 (UTC)

I'm pretty sure WP didn't even support Lua back when I developed this template, but I also don't think I've seen current examples of tables that use it (I think this thread is the first I've even seen Lua mentioned). Can you point to any that might give some indication of how a table such as this one would be implemented in Lua? Is this a thing overall in WP, of converting parserfunction code to Lua, or do you just think it would work better in this instance? (and by work better, do you just mean make the code shorter or simpler, as the table does everything it needs to at present.)

I can't see anything substituting for the power of the color-coding here to quickly and clearly communicate a lot of varying information without taking up more space, not to mention the colors' logical relationship to the kinds of opinions and votes they represent. Inserting more text would detract from and interfere with that on all scores (as it would with the map here, or the maps and tables here), as well as make the size of one column widely varying from another rather than giving them the same visual weight. My ideal solution to the OP's question would be to have a small, unobtrusive tab to the left of each row of color-coded opinion columns that, when clicked, would extend over those columns with a text description of the opinions for that case (and such text would be read by a text reader even when collapsed). I don't know if that's even possible though with current code, and the existing collapsible templates that I can find are very limited in how much they can be modified (such as the inexplicable invariability of the [show/hide] button display), which seems to be derived from the underlying code, not the templates themselves. The inflexibility of our code has really prevented a lot of innovation in how we organize and present information. postdlf (talk) 15:54, 28 June 2015 (UTC)

Not necessarily in all cases, but yes, there's a gradual move toward Lua and away from ParserFunctions since Lua a) is more efficient and b) is more powerful while c) requiring about the same level of comprehension. This isn't the case for all templates, but all of the big metatemplates (e.g. CS1 citation templates, navbox and infobox) have gone to it. I'll poke at the current version sooner rather than later to make some sense out of the template. --Izno (talk) 18:46, 28 June 2015 (UTC)

Hi postdlf and Izno. In re-reading some of my comments here, I hope I didn't give the impression that I'm criticizing the approach taken here. ParserFunctions were a perfectly cromulent way to implement this functionality at the time. We may want to switch to the newer Scribunto/Lua at some point, but there's no rush. As said before, displaying these kinds of complex decisions visually is a challenging design problem and postdlf has admirably created a working solution. Even more, he stays on top of keeping these pages up to date, which I'm continually impressed by. If this works for him and he's doing all the work, who am I to stand in the way? :-)

That said, I do continue to think that—sort of related to the accessibility concerns, but more related to general usability concerns—these table rows can be confusing to decipher. Looking at the example above, if we look at the "Case opinions" infobox section of Citizens United v. Federal Election Commission, I can see this text:

Majority	Kennedy, joined by Roberts, Scalia, Alito; Thomas (all but Part IV); Stevens, Ginsburg, Breyer, Sotomayor (only as to Part IV)
Concurrence	Roberts, joined by Alito
Concurrence	Scalia, joined by Alito; Thomas (in part)
Concur/dissent	Stevens, joined by Ginsburg, Breyer, Sotomayor
Concur/dissent	Thomas

This is a complex case, of course, but from reading this text, I can figure out pretty quickly what's going on here. When I compare that experience to looking at the table row, I'm personally not gleaning the same information nearly as quickly. I'm not colorblind, as far as I know, but even with normal vision I immediately start asking myself "what is purple?" and "what does '*' in light green mean, versus just light green?" There's a table key, to be sure, but in terms of raw speed of understanding, text is still winning here substantially, I think.

My ideal solution to the OP's question would be to have a small, unobtrusive tab to the left of each row of color-coded opinion columns that, when clicked, would extend over those columns with a text description of the opinions for that case (and such text would be read by a text reader even when collapsed).

It took me three or four reads, but now I see that we're pretty much saying the same thing here. Cool! Okay, I can do this. I have a few ideas about to how to improve the table rows. I'll make a demo of some options and link it here when it's ready. You all can tell me if any of them individually or in combination with each other would be workable.

Regarding the actual accessibility concerns here, to keep the colors, my only thought is that maybe we could add some kind of unique pattern for each color (e.g., checkered square, checkered triangle, vertical stripes, horizontal stripes, etc.)? The problem is that you'd want the pattern to be subtle, but not too subtle, and table cells can be quite small. You'd get some space back by killing the "Argued" date column, which I'm not sure is really necessary. You could kill the "Decided" date column as well and just put the year next to the case citation in parentheses. I may demo some of these visual changes as well. --MZMcBride (talk) 13:48, 21 May 2016 (UTC)

Mobile

This template doesn't render correctly on mobile (Firefox 81, Chrome 86 on Android 10). Cells that should be filled with a colour instead only have a tiny sliver of colour at the top. Hairy Dude (talk) 16:09, 1 November 2020 (UTC)

I've finally gotten around to fixing this issue, which I also ran into since I often use my phone to visit these pages (e.g., 2022 term opinions of the Supreme Court of the United States). SilverLocust 💬 19:50, 25 February 2024 (UTC)