Template talk:Infobox/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

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)

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)

there were dozens of examples in Category:Pages using infobox templates with ignored data cells but gnomes (like me) have fixed most of them. Frietjes (talk) 15:53, 26 April 2023 (UTC)

Right, so my question is, were those valid use cases where it was reasonable to allow a headerX and dataX to exist, and should we carve out an exception to actually make it work, or should we mandate good numbering protocols and give a warning if dataX and headerX are both used? Primefac (talk) 07:46, 27 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)

thank you for adding that test. I have no idea what /sandbox2 is testing either (looks pretty old). Frietjes (talk) 15:50, 26 April 2023 (UTC)

Infobox from Wikidata?

Can someone provide an example of how to populate an infobox from Wikidata?

For example, the Wikipedia article on w:American Civil Liberties Union includes a segment of code that begins "{{Infobox organization". My fantasy is that "{{Infobox Q21637}}" would be enough (because Wikidata:Q21637 is the Q ID for the American Civil Liberties Union). Then if a user wanted to include some information but not others, there would be fairly simple ways to specify information that a person wanted (a) in the article but not in Wikidata and (b) in Wikidata but not in the article.

Does documentation of how to do this exist somewhere? If yes, how can I find it? If no, can someone provide the needed documentation? Thanks, DavidMCEddy (talk) 19:39, 1 June 2023 (UTC)

Module:WikidataIB is used to pull values. There is (currently) strong community pushback against having an infobox that is entirely pulled from WD, so unless that opinion has changed, there is no point in creating an infobox that does it. Primefac (talk) 20:05, 1 June 2023 (UTC)

Thanks for the quick reply. Could you please add an example -- preferably a link to a Wikidata article that models proper use of Module:WikidataIB inside an infobox?

I believe it can be done, but I'm still not sure how. I've seen documentation of Module:WikidataIB, but I didn't see anything sufficient to get me started. It may be there, and I missed it, but it didn't jump out at me as I was trying to parse that all. Thanks again, DavidMCEddy (talk) 20:16, 1 June 2023 (UTC)

The main problem is one of verifiability. This is policy here on English Wikipedia, but whilst Wikidata has d:Wikidata:Verifiability, it's still a proposed policy or guideline; moreover, adding a source on Wikidata is much more involved than it is here - you can't simply pop the source info between <ref>...</ref> tags.

If infoboxes pull information from Wikidata, and that info gets changed, will the change be reliably sourced? Maybe. Will the change be noticed here? Not immediately, it can take days, weeks or months before somebody spots the error. But when an infobox contains the actual data in its parameters, and that info is changed, it will show up on somebody's watchlist and can be acted upon fairly quickly. --Redrose64 🌹 (talk) 21:10, 1 June 2023 (UTC)

I've experienced changes in pages I was "watching" that I could not see, perhaps because the change was to Wikidata and was not properly displayed with the change notification.

However, before I can use Module:WikidataIB to pull values, I have to know how to do it. Currently, I would be throwing darts blindfolded ;-) Thanks, DavidMCEddy (talk) 23:23, 1 June 2023 (UTC)

Take your pick, any infobox that transcludes the module will be using it. Primefac (talk) 09:20, 2 June 2023 (UTC)

Thanks. I was able to get something.

Now I have another problem: What can I do to get Wikidata: total revenue (P2139) to sort in date sequence in Pregnancy Justice (Q30288051)? When I use it in Wikipedia, the last "Revenue" entered is displayed. I think the most recent should be displayed, but that's not what I'm getting. ?? Thanks again. DavidMCEddy (talk) 13:48, 2 June 2023 (UTC)

That is a question that should be asked at WikiData - the module can be set to grab only a single P value but as far as I am aware it cannot pull a specific P value. Primefac (talk) 13:56, 2 June 2023 (UTC)

From memory our basic WikidataIB functions support preferred rank natively. See d:Help:Ranks. That should resolve the issue. Izno (talk) 14:51, 2 June 2023 (UTC)

Thanks. I just posted it to Wikidata:Wikidata:Project chat. DavidMCEddy (talk) 16:52, 2 June 2023 (UTC)

How can I get the url to display in the infobox?

I tried inserting " | official website=on" as an extra line in {{infobox organization/Wikidata ... }}. It complained, 'Preview warning: Page using Template:Infobox organization/Wikidata with unknown parameter "official website"'.

I got essentially the same error from other attempts until I tried, " | url=on". That displayed as "Website [// ]". That suggests that " | url=" is correct, but it needs to be followed by something different from "on".

This is with w:Pregnancy Justice. Suggestions? Thanks DavidMCEddy (talk) 20:47, 2 June 2023 (UTC)

Please do not do sandbox testing on live articles. Gonnym (talk) 22:50, 2 June 2023 (UTC)

The best place to start with this specific question is Template talk:Infobox organization/Wikidata. – Jonesey95 (talk) 23:48, 2 June 2023 (UTC)

Thanks. Done. DavidMCEddy (talk) 02:17, 3 June 2023 (UTC)

RfC

Your input is desired at a new Request for Comment at Template talk:Infobox company#Align the infobox?. ɱ (talk) 14:10, 19 July 2023 (UTC)

Partial collapse

Greetings. MOS:COLLAPSE says: "A few infoboxes also use pre-collapsed sections for infrequently accessed details." Could any one help me find those cases, please? fgnievinski (talk) 19:48, 8 August 2023 (UTC)

{{infobox software}} off the cuff. Izno (talk) 20:48, 8 August 2023 (UTC)

Also {{Infobox Belgium municipality}}, {{Infobox Bible translation}}, {{Infobox Greece place}}, {{Infobox number system}}, {{Infobox OS}}, {{Infobox pharaoh}}, {{Infobox U.S. federal court}}, {{Infobox website}}. This list is not exhaustive. --Redrose64 🌹 (talk) 21:12, 8 August 2023 (UTC)

Thank you both, Izno and Redrose64. Would any of you be able to help me finish a semi-collapsed draft of {{infobox journal}}, please? It'd be valuable for an ongoing discussion (Wikipedia talk:Notability (academic journals)#RfC on notability criteria). I've sandboxed it at Template:Infobox journal/sandbox2 but the tests at Template:Infobox_journal/testcases2 didn't seem to hide anything. It'd be used in Draft:List_of_American_Medical_Association_journals. Thanks! fgnievinski (talk) 04:43, 9 August 2023 (UTC)

The thing to do is to make your changes to Template:Infobox journal/sandbox, try them out at Template:Infobox journal/testcases (see WP:TESTCASES), then if all is OK, make a protected edit request at Template talk:Infobox journal (see Template:edit template-protected). --Redrose64 🌹 (talk) 18:02, 9 August 2023 (UTC)

That's equivalent to what I'm doing: making my changes to Template:Infobox journal/sandbox2 and trying them out at Template:Infobox journal/testcases2. The suffix "2" is because the original template is supposed to be left unchanged. If everything goes well, we'll have an alternative Template:Infobox journal2. The problem for the moment is I can't seem to make {{hidden}} to make any difference. fgnievinski (talk) 23:31, 9 August 2023 (UTC)

Now I've managed to make it work by using {{Collapsed infobox section begin}} instad of plain {{hidden begin}}! fgnievinski (talk) 23:31, 9 August 2023 (UTC)

Module localization

Hello colleagues! I tried to localize the Module:Infobox into the Kazakh Wikipedia. It seems like everything worked out, but some rows like headers are not aligned in the center, I can’t understand where the problem is, everything seems to be the same as in the English version. kk:Module:Ақпар қорабы for example u can see this template kk:Үлгі:Музыкалық топ, and article kk:Ұлытау тобы --Amangeldi Mukhamejan (talk) 13:14, 26 September 2023 (UTC)

Did you copy the style sheet too? — Martin (MSGJ · talk) 13:29, 26 September 2023 (UTC)

Yes, I did. kk:Module:Infobox/styles.css--Amangeldi Mukhamejan (talk) 13:46, 26 September 2023 (UTC)

I read in a comment in the code that some of the styles still come from MediaWiki:Common.css so maybe something in there? — Martin (MSGJ · talk) 13:49, 26 September 2023 (UTC)

Indeed, some of our styles are still in Common.css. If this is not a problem for you (I can take a look in a minute), you can use the stylesheet from Module:Sandbox/Izno/infobox-styles.css. Izno (talk) 18:09, 26 September 2023 (UTC)

Thanks a lot for this--Amangeldi Mukhamejan (talk) 13:10, 28 September 2023 (UTC)

And indeed, you have about 330 pages to clean to use the module. Izno (talk) 18:12, 26 September 2023 (UTC)

May I ask, why should I clean them? Cuz of name of Module? I'll change it to Module:Infobox, it's just test page actually --Amangeldi Mukhamejan (talk) 13:10, 28 September 2023 (UTC)

No, the problem is that if the styles are in the TemplateStyles page, which should be used only by the module or one of the wrapper templates, and not in the Common.css page, those 330 pages with the infobox class won't be styled appropriately. Izno (talk) 16:39, 28 September 2023 (UTC)

Small text

I'd like clarification if small text is discouraged in all cases. These two on my watchlist are now making use of small text: [1] [2]. Leave as they are or should I revert? Mac Dreamstate (talk) 19:12, 26 September 2023 (UTC)

Yes, it is almost everywhere inappropriate to use small text in an infobox. Izno (talk) 19:45, 26 September 2023 (UTC)

Any text that falls below 85% of the normal text size for the rendered page is too small. Since the default text size in infoboxes is 88%, that means that small tags and templates should almost never be used in infobox code, whether that is within template code or in parameter values on pages. The only place in most infoboxes where it can be valid is in title/above parameters that are enlarged. – Jonesey95 (talk) 20:36, 26 September 2023 (UTC)

Postscript: I have wondered for a couple of years now how difficult it would be to detect, at the module level, whether a parameter value in e.g. |label12= or |data9= contained small tags or templates, and whether it would be worth trying. – Jonesey95 (talk) 20:37, 26 September 2023 (UTC)

Maybe a bot task for checking if a param has <small> or {{small}} in it and removing it. SWinxy (talk) 20:40, 28 September 2023 (UTC)

It would be trivial to catch uses of the HTML tag, and even trivial to add CSS to make uses of the small tag not display as 85%. It is less trivial to find {{small}} but in the realm of possible. But in this case, I think it would be better to run a bot or perhaps ask the CHECKWIKI guys to dump a list of pages where this is an issue. Izno (talk) 21:45, 28 September 2023 (UTC)

[3] – Now it's a case of WP:OTHERSTUFF. Mac Dreamstate (talk) 21:37, 10 October 2023 (UTC)

Yeah, that sort of "other stuff" revert has happened to me before. I took care of it by fixing the other articles that were listed in the helpful edit summary, and a few more. Some people are not willing to follow links to explanatory text like MOS:SMALLFONT and seem to think that consistency is more important than accessibility. A tracking category or database report would be a helpful way to find articles like this that exist in batches. – Jonesey95 (talk) 18:00, 11 October 2023 (UTC)