Wikipedia talk:WikiProject Templates

Images in templates

I've noticed a series of templates that either use or once used an image in place of a typographic symbol:

• Template:Hash-tag
• Template:Section-sign
• Template:Double-dagger
• Template:Dagger
• Template:Up-arrow
• Template:Down-arrow
• (The similar {{Number sign}} and {{Asterisk}} templates don't appear to have used image files.)

It seems a bad idea for several reasons to use images. I tested updates to the dagger and double-dagger templates based on hash-tag which uses the unicode symbol with role="img" for aria. This allows it to continue working exactly like an image with alt text for screen readers but makes the hash-tag template render as regular text that can be searched, copied, zoomed, and so on just like other text.

I notice now that the other templates have been updated to only display the Unicode character, and the documentation pages advise substitution only (no transclusion). I have several questions. Since these templates link to each other in their documentation, I thought it would be more appropriate to post here than on individual talk pages.

1. Should any of these templates still link to each other?
2. Should all or some of these templates be substitution only?
3. Should they allow alt text? If they don't allow alt text, should attempts to put alt text into the template show up in a maintenance category?
4. Should the templates use images (probably not), unicode, or html entities?
5. And once this is resolved, could a template editor or admin update Dagger and Double-dagger?

Regards, Rjjiii (talk) 00:50, 4 June 2023 (UTC)

1. These links are typical ("see also" and navboxes are routinely employed in template space), though a category of the sort would not be remiss if one does not exist yet.
2. Yes, they probably should be subst-only. Making them subst-only will probably require forcing AnomieBot to process their current transclusions.
3. The replacement for use should probably be <abbr>...</abbr> when there is "alt" text specified (probably using {{abbr}}) and nothing besides the character when it is not, or perhaps error when it is not. There may be valid uses such as in a key where the dagger has text immediately after identifying its meaning, so I tend away from erroring.
4. At this point these should probably be Unicode as I doubt any-but-the-most-obscure fonts will have issue with these fairly old Unicode characters.
5. Sure, just make the edit request if/when this discussion resolves. I might suggest advertising this discussion on those templates' talk pages.

Izno (talk) 02:21, 4 June 2023 (UTC)

I disagree with using abbr, in my mind these are convenience templates at best, which is why I converted a few of them into subst templates (i.e. use them to make things easy to type but then they go away). Primefac (talk) 06:28, 4 June 2023 (UTC)

I'm not hard over for it, treating them as pure simple subst conveniences is fine also. Abbr just preserves the function they might be serving. Izno (talk) 07:26, 4 June 2023 (UTC)

Thanks for fixing a bunch of these Primefac. I am 100% fine to leave all the subst templates as they are. For dagger, hashtag, and double-dagger we could make them subst templates as well or do something like this:

{{#if:{{{alt|}}}|<abbr role="img" aria-label="{{{alt|}}}">‡</abbr>|‡}}

Here is the code above from the sandbox "‡" compared to the current template "‡". In neither version does the alt text do anything without a screen reader. Rjjiii (talk) 16:29, 4 June 2023 (UTC)

Thanks for the thorough reply Izno. I've posted messages at the templates' talk pages and found a few more:

• Template:Asterism
• Template:Mars symbol
• Template:Venus symbol
• Template:Star of David

As these are fixed, I can add them into [ [ Category:Character templates ] ], which I guess initially did not apply since they were adding images and not characters. Rjjiii (talk) 16:30, 4 June 2023 (UTC)

[[:Category:...]] (see leading colon).

I do remember one issue that showed up with using the Unicode for some of these and that's that some of them have been co-opted by the emoji ecosystem into pretty symbols rather than our plain image renderings. The ones that are problematic should probably be documented as such. Izno (talk) 16:40, 4 June 2023 (UTC)

Tested and this turns out to be true of Venus, Mars, and Star of David. I've updated their documentation and there is likely nothing else to do for those.

Looked into this more and these (I think) were created because of this policy: MOS:NOSYMBOLS and the most recent discussion seems to be here: [1]. The templates are meant to create accessible characters.

2014 status of screen readers and typography:

https://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/

And the 2023 (recent!) update: https://www.elevenways.be/en/articles/screenreaders-special-characters

According to their big chart and personal testing, I think {{hashtag}} (pronounced "number" by default), {{therefore}} (not pronounced), and {{asterism}} (not pronounced) make sense to retain alt text, but can both be made via unicode character, abbr tag, and aria. I made demos in the sandboxes. {{Section-sign}} could have alt text as it does not seem to be pronounced. Both dagger templates could retain the alt text in case someone was stretching the template for a strange purpose, but also seem like they could just be substituted (decent support, † is read variously as "dagger" or "single dagger", the default settings in Windows 10's Narrator seem to ignore both but it seems like nobody uses this when NVDA is free??). Template:Cards seems to get by just using Unicode and the card suits have comparable support to the daggers. Rjjiii (talk) 01:49, 5 June 2023 (UTC)

Thanks for taking this on, @Rjjiii! As your saw, I've commented previously about how images are a poor choice, and I look forward to the improvements here. {{u|Sdkb}} ^talk 20:25, 6 June 2023 (UTC)

Based on responses here, testing, archived threads in en-wiki, a couple of conversations at LSD/VI, articles on screen readers, and posting to the NVDA mailing list, I think the best way to handle these are:

1. Continue to use images with alt text if mobile devices are rendering the Unicode characters as emoji,
2. Use the Unicode character with an img aria role for dagger, double-dagger, and other templates that are currently being used for notes in tables or lists, and
3. Substitute the characters when there are no issues with Unicode rendering or existing template usage.

Something brought up on the NVDA mailing list is that these characters are used on Wikipedia to emulate print media when the articles could use one of our many linked footnote methods. The Manual of Style should likely recommend that path rather than alt text for unlinked notes. Thanks for the input, Rjjiii (talk) 08:32, 14 June 2023 (UTC)

@Izno: Thanks for the explanations here and for updating {{dagger}} and {{double-dagger}}. Using title= in addition to role="img" aria-label= is fine, but I don't think it makes sense to use the title only.

• The title attribute will create a tooltip for sighted desktop users.
• The aria-label will be read aloud for images and interactive elements.

I didn't change the sandbox to a character substitution template because the Manual of Style (MOS:NOSYMBOLS) recommends using templates like this to make table colors accessible. If you check out the test cases with a screenreader, the template's alt text is only used by the sandbox version (Template:Double-dagger/testcases and Template:Dagger/testcases). Regards, Rjjiii (talk) 04:50, 25 June 2023 (UTC)

An image role is strictly inappropriate here because these are not images nor are they intended to be images (and the latter is more important for assigning a role). (I actually struggle to think of a valid use of role=image, but that's a digression. See also that roles should be avoided in the general case.)

<abbr> is strictly correct for the intent of these items, and its use of title is as expected for the variety of user agents (note, this is not the HTML global attribute title but a specialization of that attribute for that element, see the specification). If accessibility-minded user agents aren't reading out the title of an <abbr> or offering the option of doing so, that's a bug in those agents and should be filed upstream. From memory of what a particular editor (who is blind) has said, they basically do one of those two things. (Incidentally, memory also says that he thought it would get tiresome if every abbreviation were read out in full, which is why most are optional.)

aria-label also has a particular use, and it's not "give things noise", it's "something that should be noisy isn't and so you need to hack around it". I think the quote at MDN is a good comment on the point:

Note: aria-label is intended for use on interactive elements, or elements made to be interactive via other ARIA declarations, when there is no appropriate text visible in the DOM that could be referenced as a label

Izno (talk) 05:10, 25 June 2023 (UTC)

An image role is strictly inappropriate here because these are not images nor are they intended to be images [...] Izno, do you understand what I'm saying about the manual of style?

If accessibility-minded user agents aren't reading out the title of an <abbr> or offering the option of doing so, that's a bug in those agents [...] Is it? https://www.powermapper.com/tests/screen-readers/labelling/acronym-abbr-title/ Rjjiii (talk) 06:40, 25 June 2023 (UTC)

Yes, accessibility agents failing to use HTML as intended is a bug. But even if it weren't, the readouts at your provided test are absolutely fine to me.

JAWS has an 'Expand Abbreviations' setting which does read `abbr title`, but this is turned off by default and these tests use default AT settings. was alluded to above. If random website producers are going to use defaults when non-defaults are available, that's on the test makers, not the tested software. I would absolutely expect this to be one of those things that some users would prefer to have read out and others prefer to hear whatever the abbreviation is.

a character substitution template I don't think you understand what we meant by subst above? I don't see the point of this comment otherwise. Izno (talk) 15:20, 25 June 2023 (UTC)

The change appears to have generated a dotted underline for the templates, which I don't think is what users of them will be seeking. {{u|Sdkb}} ^talk 20:08, 25 June 2023 (UTC)

That can be changed with style="text-decoration: none" which I have no strong opinion about. Izno (talk) 20:55, 25 June 2023 (UTC)

Oh, I think I realize why my responses may sound strange. What screen reader are you testing with? I don't have access to JAWS. Perhaps I should have been more clear about what I'm using. I have tested with the built-in VoiceOver software on an iPad (not sure which version), NVDA (2023.1, up to date), and the Windows 10 Narrator (2020? version, up to date).

• On the iPad and NVDA, I hear "dagger" regardless of the title generated from the |alt= parameter.
• With the Windows Narrator, I hear nothing. (This may not be a huge deal, as it seems people on Windows use mostly JAWS or NVDA.)

Apple and NVDA don't offer a setting like JAWS ( https://openinclusion.com/blog/presenting-abbreviations-acronyms-for-screen-reader-users/ ). So, when I'm testing with these readers, there is no audible difference between † and <abbr title="deceased">†</abbr>. Rjjiii (talk) 03:13, 26 June 2023 (UTC)

And by a character substitution template I meant a template that would create a single character, and that could be used primarily or only via substitution rather than transclusion. As I said about some of the templates like {{section-sign}} in my initial post: I notice now that the other templates have been updated to only display the Unicode character, and the documentation pages advise substitution only (no transclusion). Rjjiii (talk) 03:17, 26 June 2023 (UTC)

Izno, Primefac, and Sdkb, let me get your input before I make changes and put in requests.

The templates do not currently generate audible content from the |alt= parameter on most screen reader setups. NVDA, Apple's VoiceOver, and the Windows Narrator don't appear to read the title attribute of the abbr tag. JAWS, by default, will not read it. Instead, the parameter will generate a tooltip only available to sighted desktop users with a pointing device.

The Manual of Style advises using templates like this to create accessible glyphs in tables (MOS:NOSYMBOLS). Users with color blindness, poor vision, or no vision would still be able to perceive the glyph, even if they could not perceive meaningful colors. I think the recent updates are still an improvement over the use of inline images sized by pixels, but I don't think it makes sense to use the alt parameter this way. Here are the two good options from my perspective:

1. Make the templates each only provide a single Unicode character or html entity. Primefac has already updated some of the templates to do this. Later, I can work on updating the Manual of Style to allow typographic symbols that have gained widespread support since the policies were originally written. (Many pages already use *, †, or ‡, and most screen readers will read those characters as "star", "dagger"/"single-dagger", and "double dagger".)
2. Use an aria-label and role="img" to make screen readers treat the typographic glyphs as images with alt text. {{Hash-tag}} has worked like this since this edit from GreenComputer: [2]. This could be used alongside the tooltip recently introduced as in the current sandbox for that template (Template:Hash-tag/testcases).

Based on the posts above, I expect the consensus to be on the first option but wanted to make clear why these templates worked so differently from something like {{asterisk}} which has always just generated the HTML entity to make safe wikitext. Appreciate you guys looking into this, Rjjiii (talk) 03:31, 27 June 2023 (UTC)

I can understand having alternate options for weird or little-used unicode, but # is well-known as hash/pound and has been on keyboards and in use for decades. {{hash-tag}} seems more like a safe-wikitext template like {{asterisk}} rather than a "typing aid" template like {{left arrow}} or a possible unicode fix like {{section-sign}}. My thought is that if it's in the bottom of the source editor (i.e. all of the listed templates) and screen readers don't have issue with them, treat them as convenience templates and make them all subst-only single characters. Primefac (talk) 07:26, 27 June 2023 (UTC)

I'm fine with making subst only single characters. Izno (talk) 21:07, 27 June 2023 (UTC)

Feedback requested at proposal to enhance Module:Excerpt

A proposal is under discussion to enhance transparency and navigability of Module:Excerpt. Your feedback would be appreciated at Module talk:Excerpt#Proposal: pre-load a helpful preview editintro notice on clicking 'edit' in hatnote. Thanks, Mathglot (talk) 17:36, 9 July 2023 (UTC)

Notice

There is a discussion at Template talk:R from fictional character that may concern this WikiProject. QuicoleJR (talk) 13:51, 14 August 2023 (UTC)

Wikipedia:Map data

Is there any reason, technical or otherwise, that Wikipedia:Map data and its sub-pages are in the project namespace and not in the template one? Looking at a page like Wikipedia:Map data/10th Ward of New Orleans shows that it is transcluded in articles similar to other data templates. Gonnym (talk) 10:19, 16 August 2023 (UTC)

{{Map data}} doesn't (currently) exist, so I would have no issue with moving the template family. Granted, I have no idea why it was created in the WP space and the creator is on another extended absence. Primefac (talk) 10:24, 16 August 2023 (UTC)

Proposed minor change to Module:Hatnote list

I proposed a minor change some months ago at Module talk:Hatnote list about how Module:Hatnote list handles "italicized" text with final punctuation. Module:Hatnote list is used by templates like {{About}}. No discussion happened when I posted it there, but I still think it should be implemented. Some eyes on it are appreciated. LightNightLights (talk • contribs) 09:48, 19 August 2023 (UTC)

Notice

There is a move discussion at Template talk:NoteTag that may be of interest to this wikiproject. Sennecaster (Chat) 04:34, 2 September 2023 (UTC)

Input requested about DEFAULTSORT

Hello. There is opposition to linking to {{DEFAULTSORT}} magic word/template that I'm not understanding, at Help talk:Category#Wikilink to Template:DEFAULTSORT. If you have the time or interest to help explain things that would be appreciated. Regards, Thinker78 (talk) 19:53, 9 September 2023 (UTC)

Discussion at Wikipedia:Redirects for discussion/Log/2023 September 7

 You are invited to join the discussion at Wikipedia:Redirects for discussion/Log/2023 September 7#Template:R from deadname, which is within the scope of this WikiProject. This discussion may lead to the creation of a new rcat template, so I’m notifying WP:WPTEMP in case any members of this WikiProject wish to join the discussion. (Apologies if this notification is unnecessary or inappropriate.) All the best, ^{— user:}A smart kitten_meow 18:52, 10 September 2023 (UTC)