Template talk:Infobox

Infobox accessibility for screen readers

Recently, I've been looking into how well our articles are accessible by screen-reader software such as Voiceover on a mac (command-F5), and for infoboxes it's a little wonky. If you've never used screen-reader software, the idea is that since users can't visually scan to jump to a type of content, the software will list out the elements of a given type that are present, such as tables or links. The Infobox, being a table, is the first one of that type to be listed - but the listing is generally useless and unhelpful.

The docs for Infobox say that "title" and "above" are roughly equivalent, though it notes that "the most recommended alternative" is title. And so, for articles with infobox types that do that, like Lego (Infobox toy), the screen reader software tells you that the first table in the page is named... "Lego". No context for what that means. Many infobox types, however, don't use title- so for those, like Final Fantasy X (Infobox video game), you get... nothing. You just get told that the first table has "2 columns, 16 rows", with absolutely zero context whatsoever.

So, we could of course find the variants that don't use title and fix that, but honestly a table named "Lego" on an article named "Lego" tells me nothing about what's in it, so if I didn't know that it was an infobox with details about the subject I wouldn't be able to tell. So neither is great. The solution, it seems to me, is to add caption text in both cases that specifies what it is- so "Lego summary details" if there is a title, and just "Summary details" if there isn't. Obviously we wouldn't want to display that added text to non-screen-readers, but we have that solved already with e.g. {{Screen reader-only}} - the "sr-only" css class from {{Screen reader-only/styles.css}} lets text be read by screen-reader software without adding visual clutter to visual browsers.

The changes needed would be adding the css class and updating local function renderTitle() (line 165) to a) always have a caption element) and b) append <span class="sronly"> summary details</span> inside of that caption. I wanted to get consensus for this, however, before I went mucking with the sandbox. Thoughts? --PresN 15:51, 17 October 2022 (UTC)

The material difference between these two from an accessibility perspective will go away when infobox gets changed to <div> from <table> (because it's not really an HTML table). That's maybe a year or two away. It's currently blocked on getting infobox over to TemplateStyles.

When we get to that state, I have been thinking about how to make it obvious in accessibility agents what they've bumped into. I think we can do that with a simple aria-label which I think we could just set to aria-label="info box" (I'd prefer to ke. Well, at least as specced by the W3C; MDN looks a bit opinionated about the expectation that the element you're giving a label to should be interactive.

We could probably do that today on the full table element. User:Izno#Testing has a table with it and Firefox seems to pick up that that's the name of the table. I don't know what that sounds like in voice over. We could use text from |title=/|above=, but the problem is that those two places can contain other HTML, so then we're looking ripping out that other HTML while parsing (not fun). aria-labelledby could be used for that case but it would require the introduction of IDs to the infobox elements for title/above, and I can't guarantee unique IDs on a page today (i.e. pages can contain multiple infoboxes). phab:T200517 would help with that. We could also take the ID from the |name= for infoboxes with a name (which also adds {{navbar}}) and a potential |aria-label= for infoboxes without, which would probably get us most of the way there. But all of those are probably optimmizations on the more general "name the box for screen readers" for which "info box" or some variant probably is Good Enough? Izno (talk) 18:16, 17 October 2022 (UTC)

@Izno: Voiceover reads it as "info box" (though screen readers read fast so it's indistinguishable from "infobox"). That'd be better than the nothing we have today for non-titled infoboxes, so if that's what we get that's sufficient (though I'd personally prefer "summary details" as more clear, but whatever).

In any case, I guess I'm a little confused? Like, I get that the infobox is doing weird things internally, but as far as what's going on today rather than a year from now it's clearly coming up as a <table> element with the name of whatever is in the title field if present in a <caption> element. And that caption is what is read by screen-readers to identify the table. I just checked- if you have links or tags in the title, like if it's "Lego Lego Lego^Lego", then the screen reader just reads out the words "Lego Lego LegoLego", no addendums. So, no need to parse anything as far as html goes for the caption tag. It sounds like there are multiple issues with trying to do aria tags today, so wouldn't the best solution (for now, until infobox gets TemplateStyles) be just to add invisitext to the caption element? --PresN 19:53, 17 October 2022 (UTC)

@PresN, I fundamentally dislike outputting stuff that's hidden in this way, is probably my answer. I don't like that we have tables elsewhere that do it en masse either, but I didn't speak up in those cases because I thought the motivations were reasonable if not supported everywhere so well as they should be.

The reason I mentioned the future was to note that there is an alternative implementation and that the other solution also both works and is something that could be taken into the future, vice using caption, which can't be. (Without presuming on my part that future will come to be.)

The problems with the aria implementation are for a "cleaner" solution using aria, not for a solution that doesn't work, given the text you think could/should be added.

The actual root fix of course is to change our templates to get the titles into the caption element. We could also spin up a category for that and/or soften how large the title is (the probably dominant reason some titles end up in |above= or one of the other not-caption elements at the top of the infobox). Izno (talk) 01:03, 17 December 2022 (UTC)

As an experienced screen reader user, I've honestly never ever thought of this as a problem and I think changing things now would just add more verbiage for very little benefit. As for making infoboxes into divs rather than tables, I'm not sure what I think of that ... I've always seen them as data tables with columns and rows and have always appreciated being able to use screen reader table navigation commands to skim-read/skip past them. Graham87 08:36, 18 October 2022 (UTC)

Yeah, I can appreciate that view of them. In the general case though, the fact it's a table makes it horrific to work with infoboxes at smaller resolutions and/or inaccessible for other reasons there, since there were/still are readers that will interpret display: block for <table> pretty badly, which is what is needed at the uber small res (and which is what mobile does today), and even displaying browsers cough and hack on the difference in display modes (random scrollbars, things extending outside the content width, etc. etc.). I've put some musings together at user:Izno/Sandbox/Infobox. As you can see there, there's a version of it which is based on definition lists (though IDK if that use is precisely kosher), but there could be a form of infobox which is a series of lists (first of headers and then a list for each header), but that form has issues with integration with CSS grid, which is probably the display technology of interest here (notably that we don't have subgrids widely available yet). It's not an any time soon thing though with TemplateStyles still to go, among the other TableAsPresentationThings we have that would probably make the world better to definitely fix at some point. I know of another wiki that pretty early on (like a decade and a half ago) realized that infoboxes are just unordered lists of info and has marked them up as such also; most others copy-paste us or use wikitext tables.

If I were to note, you probably don't notice (or maybe aren't served/delivered?) that the information contained in Google's infoboxes is <div> based rather than table based. Besides Google (and a few other search engines), there aren't really any other web properties doing infoboxes in a sense like ours (or at least the world of MediaWiki), where most other wikis just copy what we do. Izno (talk) 00:27, 17 December 2022 (UTC)

box-wide data field

What would be a good option to present |datan= in box-wide column instead of regular columnwide (righthand side)? Could be some css form, could be a child-infobox. Preferably, left-align should be possible too. DePiep (talk) 14:44, 28 November 2022 (UTC)

I don't understand what you are asking for. If you use e.g. |data1= without also using |label1=, it occupies the full width. --Redrose64 🌹 (talk) 18:43, 28 November 2022 (UTC)

TemplateStyles for plainlist

I've made a change in the sandbox which allows for automatic detection of plainlist class (today) to insert the relevant styles as TemplateStyles. This is essentially as described at Template talk:Navbox#TemplateStyles for plainlist part 1. If you have questions, please feel free to inquire over there.

I also noticed that the module was calling {{italic title}} rather than its module interface, and so there is a change queued for that as well. I noticed a discussion in the archives about accessing the full function of that module, but I leave others to work on that in the arbitrary future. Izno (talk) 00:17, 17 December 2022 (UTC)

Ignored data cells

A few years ago, Frietjes added tracking for ignored data cells (see this thread). I just fixed about a dozen of these today. Does anyone object to allowing both |header1= and |data1= with the header appearing over the data similar to {{sidebar}}. I think this would eliminate a lot of confusion. Thanks! Plastikspork _―Œ^(talk) 13:38, 25 April 2023 (UTC)

Sounds like a good idea. Could you do a mock-up of what it would look like? — Martin (MSGJ · talk) 14:48, 25 April 2023 (UTC)

yes, now that we have allowed sufficient time for the tracking category to fill, and the tracking category is cleaned up, I think we can safely do this. I think this change should do it. basically, just change the logic that excludes both from appearing, and remove the extra tracking. you can see the difference in this test. Frietjes (talk) 15:18, 25 April 2023 (UTC)

Looks good! — Martin (MSGJ · talk) 17:15, 25 April 2023 (UTC)

Yes, that looks great! Plastikspork _―Œ^(talk) 01:01, 26 April 2023 (UTC)

What would be the motivation for making infobox work like sidebar in this case, and is there an already existing alternative? I think there is always at least one alternative - just using the next number. Izno (talk) 18:39, 25 April 2023 (UTC)

The problem is that if you use the same header and data number it suppresses the data with no error or warnings, just a tracking category. I just fixed about a dozen of these where the data wasn't showing. I don't see any downside to allowing the header and data to have the same number. Plastikspork _―Œ^(talk) 01:01, 26 April 2023 (UTC)

That wasn't really my question. I'm looking for a real-wiki use case that actually needs to add this support. If there isn't one, that's fine..... Izno (talk) 01:40, 26 April 2023 (UTC)

I think this fix is meant to allow for mistakes where someone accidentally dual-numbers the header and subsequent data value. In other words, rather than posting a warning or creating an entry in a tracking cat, we are just going to allow it as a reasonable exception. Primefac (talk) 08:04, 26 April 2023 (UTC)

So, as I understand it, a |datan= will show, right below |headern=. Is this sound semantically? DePiep (talk) 07:40, 26 April 2023 (UTC)

Tests |autoheaders=true added: § Eccentric styles autoheaders. /sandbox: as expected ("no data -> no header"). Don't know what /sandbox2 is testing. -DePiep (talk) 07:55, 26 April 2023 (UTC)