Wikipedia talk:WikiProject Accessibility/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Icon(s) to represent 'changed from/to'

I am building a table of locomotive classes, represented by 4-digit numbers. Some classes were renumbered. So if the Class 3100 locomotives were renumbered as Class 5100, there would be two items in the relevant boxes in the table:

• 3100 ( > 5100)
• (3100 > ) 5100

The first would indicate that the 3100 class later changed to 5100, the second that the 5100 class had previously been 3100. MOS says that I cannot use ASCII (eg '>') as an icon for accessibility reasons. How do I find an icon that says 'changed to' ? (And are the brackets a problem?)

--Verbarson (talk) 16:04, 10 February 2021 (UTC)

@Verbarson: Those symbols (including the parentheses) will be read out fine by screen readers; their meaning would be unclear without an explanation though. Graham87 07:04, 11 February 2021 (UTC)

@Graham87 Thanks. I will provide a legend to explain the structure of the information, and the meaning of the symbols. --Verbarson (talk) 09:40, 11 February 2021 (UTC)

Wikidata proposal for alt text property

There is a suggestion at wikidata:Wikidata:Property proposal/alt text to allow adding alt text to Commons images using Wikidata. Users with accessibility knowledge may wish to provide feedback. the wub "?!" 20:59, 22 February 2021 (UTC)

Font gimmicks

I've started a discussion about disallowing "font gimmicks" site-wide as part of the MOS at Wikipedia talk:Manual of Style/Accessibility#Font gimmicks. I thought this WikiProject might be interested. Woodroar (talk) 00:50, 28 February 2021 (UTC)

Accessibility of two video game list templates

Hi all, last night I added "caption" parameters to two templates that are often used for video game lists, {{Video game titles}} and {{Video game table}}. (Example lists: List of Blizzard Entertainment games for "titles", List of Mystery Dungeon video games for "table".) Another editor raised the point that the resulting output of these templates may be "layout tables" rather than "data tables" as per WP:DTAB, as while they have row and column relationships they also do some things with visual layout. If so, they should not get captions and are in fact contra-indicated altogether. Can anyone verify whether these template tables are actually parseable by screen readers, and if they should or should not get table captions? Thanks! --PresN 16:02, 15 March 2021 (UTC)

@PresN: Thanks for that. They parse fine here ... and I think they are indeed data tables because they have a consistent number of columns that display data in a tabular format. Graham87 06:38, 16 March 2021 (UTC)

@Graham87: Thanks you! I'll carry on with using captions for them then. --PresN 13:59, 16 March 2021 (UTC)

Precomposed fraction characters such as ¼ in category names

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Categories for discussion/Log/2021 March 3#Category:10¼ in gauge railways in England regarding the use of precomposed fraction characters such as ¼ in category names. --Redrose64 🌹 (talk) 23:37, 21 March 2021 (UTC)

Relevant discussion at MOS:TABLE

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/Tables#Conflicting guidance on headers, which concerns MOS guidance on "year" and "title" columns in tables (specifically, which column should be the rowheader, and the ordering of the two columns). — Goszei (talk) 06:36, 24 March 2021 (UTC)

Solar System ignoring SMALLTEXT

Solar System has a mix of {{smaller}} and other formatting in the infobox that ignores MOS:SMALLTEXT. Walter Görlitz (talk) 03:34, 20 April 2021 (UTC)

 Done --Redrose64 🌹 (talk) 16:52, 20 April 2021 (UTC)

Discussion of Template:Life timeline and MOS:SMALLFONT

There is a discussion of how and whether to modify {{Life timeline}} (a graphical timeline that shows the history of life over the last 4500 million years) to obey the accessibility guideline to avoid small fonts. You're welcome to join in the discussion here. — hike395 (talk) 06:53, 14 May 2021 (UTC)

RfC about the colour schemes used for professional wrestling navigational templates

FYI

 – Pointer to relevant discussion elsewhere.

Please see Template talk:WCW World Television Championship#RfC about the colour schemes used for professional wrestling navigational templates. --Redrose64 🌹 (talk) 20:58, 4 June 2021 (UTC)

Blank lines before stub templates?

I have a question - I may have misread the Accessibility MOS, but outside of lists, does leaving doubled-up blank lines between, say, categories and then stub templates impact accessibility?

I removed them here, but this was then reverted, with the explanation that it's standard practice to leave that gap between templates.

Have I misread the MOS and thought that double blank lines anywhere impacts reading as a blank line in a list would do? I'd appreciate some input. Thanks! --Ineffablebookkeeper (talk) 17:13, 19 July 2021 (UTC)

@Ineffablebookkeeper and Peter coxhead: It's not within a list, and it doesn't affect accessibility. The only difference is that the two-blank-line format emits the HTML

<p>
  <br>
</p>

which is absent from the one-blank-line format, and I'm certain that screen readers will take this in their stride.

At one time the second blank line was necessary for certain bots and scripts to correctly detect the stub template, but I believe that this is no longer the case; but WP:STUBSPACING still suggests two blank lines. Personally speaking, if there are no blank lines, I add one; if there are three or more, I remove sufficient to leave two; if there are one or two, I leave them alone. It's really not worth WP:EWing about. --Redrose64 🌹 (talk) 19:02, 19 July 2021 (UTC)

@Redrose64 and Ineffablebookkeeper: WP:STUBSPACING is a guideline, so I suppose you can say "suggests" but it's written as an instruction: Leave two blank lines between the first stub template and whatever precedes it. It's certainly not something to edit war about, we agree; I reverted to make the point that editors should not be changing two blank lines here to one. Peter coxhead (talk) 21:49, 19 July 2021 (UTC)

@Peter coxhead:, @Redrose64: - I agree, this isn't something to edit war about, and I'm if I came off as snarky - my point was more along the lines of me not always having the best grasp of Wikipedia's many guidelines(!). I wanted to make sure I was going about with best practice, so I figured I'd ask. -- Ineffablebookkeeper (talk) 21:53, 19 July 2021 (UTC)

@Ineffablebookkeeper: I'm not sure if any editor can ever grasp all of the English Wikipedia's many guidelines; I certainly wouldn't claim to have done so after getting on for 12 years of editing! Two blank lines before a stub template just happens to be one that I do remember, probably because I often create stubs. Peter coxhead (talk) 22:00, 19 July 2021 (UTC)

Not a problem! I wonder if we couldn't have some sort of Olympics for remembering Wikipedia guidelines...special points given out for Ye Olde Wikipedian Guidelines, of course.(!) -- Ineffablebookkeeper (talk) 22:03, 19 July 2021 (UTC)

@Ineffablebookkeeper: Leaving blank lines in lists, as you did here, does cause accessibility issues. --Redrose64 🌹 (talk) 22:32, 19 July 2021 (UTC)

Ah, right you are - apologies. -- Ineffablebookkeeper (talk) 10:53, 20 July 2021 (UTC)

Hold on - curious thing is, @Redrose64:, I didn't actually *enter* a blank line there manually. It seems that leaving a reply on mobile automatically inserts one - having just gone to desktop view on mobile for this edit, I can see that it added a blank line to every reply entered on mobile.

Which seems odd. There's a lot of oddities of mobile editing, but it seems to presume a list formatting without the user's involvement. Seems like an issue that could need fixing, tbh. --Ineffablebookkeeper (talk) 10:58, 20 July 2021 (UTC)

Are the graphs in Greenhouse gas emissions by Turkey OK?

Hello,

Could any of you guys check them as I will be putting the article in for FAC very soon and have had a comment from my FA mentor at Talk:Greenhouse_gas_emissions_by_Turkey#Pre-FA_thoughts?

If you are pressed for time please let me know first about the graph in Greenhouse_gas_emissions_by_Turkey#Mitigation

Thanks in advance

Chidgk1 (talk) 08:44, 15 September 2021 (UTC)

I didn't even look at the graphs, the most glaringly obvious accessibility issue on that thread was the massive disregard for WP:LISTGAP, which I have fixed. --Redrose64 🌹 (talk) 20:52, 15 September 2021 (UTC)

Thank you so much for fixing that. As I hope to get the article to FA if anyone can spot any accessibility issues at all I would be most grateful if you could ping me. Chidgk1 (talk) 06:42, 16 September 2021 (UTC)

Discussion at Talk:List of screw drives § Images in Section Headings

 You are invited to join the discussion at Talk:List of screw drives § Images in Section Headings. — Marchjuly (talk) 04:13, 15 October 2021 (UTC)

Discussion about bot to fix indentations in discussions

FYI

 – Pointer to relevant discussion elsewhere.

Please see WP:BOTREQ#Bot to fix indents. – SD0001 (talk) 07:56, 11 October 2021 (UTC)

The bot is now undergoing trials. See Wikipedia:Bots/Requests for approval/IndentBot. Winston (talk) 23:29, 22 October 2021 (UTC)

Discussion at Wikipedia talk:WikiProject California § Navbox color

 You are invited to join the discussion at Wikipedia talk:WikiProject California § Navbox color. {{u|Sdkb}} ^talk 02:41, 23 October 2021 (UTC)

Discussion at Wikipedia talk:WikiProject Weather § RfC: Changing the color scheme for storm colors to make it more accessible

 You are invited to join the discussion at Wikipedia talk:WikiProject Weather § RfC: Changing the color scheme for storm colors to make it more accessible. Chlod (say hi!) 17:52, 17 November 2021 (UTC)

"This is not a paywall" paywall

I don't know where to tell people this so here it goes.

The paywall that says "This is not a paywall" takes up an enormous amount of the screen for people with disabilities who have to scale up.

I wouldn't be caught dead giving Wikipedia money as I'd rather it be broken up into a dozen or more smaller wikis so that no one of them gets the massive undue political influence Wikipedia wields in society, mostly for evil. But I thought someone would like to know before we get start getting browser extensions specifically designed to disable Wikipedia nagging. --2601:300:4080:6230:441A:91B:9FF:7BDD (talk) 00:44, 2 December 2021 (UTC)

Suggestions please - re Australian Government structure diagram

Any suggestions please for improving accessibility of the following diagram:

Structure of the Government of Australia

Regards. Aoziwe (talk) 13:00, 12 December 2021 (UTC)

The accessibility seems OK to me as a totally blind person. However, I fixed the typos in the image description where it's used at Politics of Australia and Australian Government. These typos shouldn't be corrected in other places, however. Graham87 14:04, 12 December 2021 (UTC)

Thanks Graham. I have fixed the typo in the diagram too. Aoziwe (talk) 03:49, 13 December 2021 (UTC)

Request for bot fix to contrast issue on awards pages

Example colour contrast

	Blue	Wheat
Red (Vector legacy)	Red 3.82:1	Red 5.17:1
Red (Vector new)	Red 2.56:1	Red 3.47:1
Blue text	Blue 4.79:1	Blue 6.49:1
Black text	Black 11.79:1	Black 15.98:1

Having done some work on some of the Hugo Award winners today, I've noticed that the winners are highlighted with a blue background of #b0c4de  , which has a contrast ratio of 3.82:1 for red links, 4.79:1 for blue links and 11.79:1 for black text — WebAIM's Contrast Checker tells me that's a WCAG AA fail for red, a narrow AA pass (and AAA fail) for blue text and a AAA pass for black. (To save anyone looking it up, "normal text" should be 4.5:1 or greater for AA, 7:1 for AAA.)

Having not checked the numbers but merely found it very difficult to read, I boldly changed the background to #f5deb3  , the named HTML colour "wheat", which is a WCAG AA pass for all 3 colours (but still a AAA fail for red and blue). Not unreasonably, someone reverted my change with a comment of "keep consistent style across all hugo pages".

(I've added the redlink colour for both the legacy Vector skin and the newer Vector skin to the table above. Note that, while new Vector uses a brighter redlink colour of #dd3333  , the only AA-passing yellowish background for that red would be #ffffee  , which is barely distinguishable from white or from the background #f8f9fa   of the rest of the table rows. As a result, I am not recommending that colour.)

Could someone with a bot or AutoWikiBrowser go through the articles for these awards (all the pages within the primary category Category:Hugo Awards and also the pages within Category:Nebula Awards, in both cases non-recursively) and change #b0c4de to #f5deb3 (as a case-insensitive match), please? — OwenBlacker (he/him; Talk; please {{ping}} me in replies) 20:36, 19 December 2021 (UTC)

Maps

Are there any considerations for maps other than those covered at MOS:COLOR? ◅ Sebastian 13:10, 20 December 2021 (UTC)

Discussion about redirects and typos

Hi, there's an RfC at Wikipedia talk:Criteria for speedy deletion about having typos as redirects. I don't understand redirects well enough to make an actual comment at the RFC, but I am notifying here because typing error and spelling error redirects are going to be most helpful to people with disability. --Xurizuri (talk) 04:13, 9 February 2022 (UTC)

Template:Yes has an RFC

Template:Yes has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. --Fernando Trebien (talk) 20:15, 20 February 2022 (UTC)

Blank lines following section headings

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style#Spacing RfC. --Redrose64 🌹 (talk) 22:34, 20 February 2022 (UTC)

Discussion at Template talk:Edit taxonomy § Pencil icon, 2022

 You are invited to join the discussion at Template talk:Edit taxonomy § Pencil icon, 2022. {{u|Sdkb}} ^talk 10:04, 9 March 2022 (UTC)

Discussion at Wikipedia talk:WikiProject Weather

There is a discussion at WikiProject Weather regarding the accessibility of track maps, templates/infoboxes, and timelines for the colorblind community. Feedback would be appreciated. Noah^Talk 22:04, 21 March 2022 (UTC)

Discussion about all-caps text at Talk:The Masked Singer (American season 4)

There's the start of a discussion at Talk:The Masked Singer (American season 4)#All-caps in table.

The table looks like this (I've redacted names to avoid spoilers)

Results

Stage name	Celebrity	Occupation(s)	Episodes
			1	2	3	4	5	6	7	8	9	10	12
			Group A	Group B	A	B	Group C		A	B	C
(redacted)	(redacted)	(redacted)	SAFE		SAFE				WIN			WIN	WINNER
(redacted)	(redacted)	(redacted)					SAFE	SAFE			RISK	WIN	RUNNER-UP
(redacted)	(redacted)	(redacted)		SAFE		SAFE				SAFE		WIN	THIRD
(redacted)	(redacted)	(redacted)		SAFE		SAFE				SAFE		OUT
(redacted)	(redacted)	(redacted)					SAFE	SAFE			WIN	OUT
(redacted)	(redacted)	(redacted)	SAFE		SAFE				RISK			OUT

I'm not wild about the colour contrast, which could certainly be improved, but I find all-caps text difficult to read, so that's what caught my attention.

If you'd like to engage in the discussion, please do so there. — OwenBlacker (he/him; Talk; please {{ping}} me in replies) 10:08, 26 March 2022 (UTC)

Discussion regarding map colours on 2022 Russian invasion of Ukraine

Just thought I'd alert the WikiProject to this Talk:2022_Russian_invasion_of_Ukraine#Map_is_useless_for_color-blind_people. — Czello 09:16, 2 April 2022 (UTC)

The Convert template and fractional values

FYI

 – Pointer to relevant discussion elsewhere.

Please see Talk:East Lancashire Railway#The convert thing. This concerns how screen readers call out constructs like 12+1⁄2-mile (20 km). --Redrose64 🌹 (talk) 11:55, 5 April 2022 (UTC)

Feedback request at Talk:2022 Russian invasion of Ukraine#Changing the main map to the colourblind-friendly version

Hi all. I would like to invite editors from Wikipedia:WikiProject Accessibility to offer their feedback in the discussion Talk:2022 Russian invasion of Ukraine#Changing the main map to the colourblind-friendly version. Thanks! Melmann 18:02, 19 April 2022 (UTC)

Discussion at Wikipedia:Edit filter/False positives/Reports § Hegelaci

There's a discussion at Wikipedia:Edit filter/False positives/Reports § Hegelaci about off-left tripping an edit filter about absolute positioning. WikiProject participants may wish to contribute there. — OwenBlacker (he/him; Talk; please {{ping}} me in replies) 10:18, 2 May 2022 (UTC)

Feedback requested – attempted addition of screen-reader compatibility to {{Scarf}}

I was trying to work out how to add alt text to the {{Scarf}} template which produces a visual representation of an academic scarf. Because it's implemented as a table, to allow for taking up variable width, editor-specified colours etc. (even though it acts more like an image) it doesn't have an alt attribute.

The solution I came up with was a "description" parameter which, if used, renders the provided text as a screenreader-only snippet and adds the aria-hidden="true" attribute to the table. The intent is for screenreaders to completely ignore the table and just read a hidden description of the pattern.

I've added descriptions to some of the built-in patterns. Here is how they appear:

Newnham College— Scarf colours: grey, with a central broad band of navy, itself divided in two by a narrow gold stripe

King's College— Scarf colours: royal purple, with two equally-spaced narrow white stripes

Jesus College— Scarf colours: three equal stripes of red and black, with red in the middle on one side of the scarf, and black in the middle on the other

Is that an improvement? To me, when I turn my screenreader on it now describes the pattern and doesn't cause any unanticipated issues. But I don't ordinarily use a screenreader so I would like some feedback from those who do on whether this is a helpful change before adding any more descriptions. Charlie A. (talk) 15:11, 13 May 2022 (UTC)

@Charlie A.: Thanks, that's much better! There is actually a template for this kind of situation, {{Screen reader-only}}, which could be more appropriate (but I don't really know what the advantages/disadvantages are between your approach and the templates'). The pseudo-alt text reads fine in both the Windows screen readers I have here. I had no idea about the existence of the scarf template before, let alone its previous inaccessibility. Graham87 08:39, 14 May 2022 (UTC)

@Charlie Awesome: Redoing ping. Graham87 08:40, 14 May 2022 (UTC)

Great, glad it works as expected for you too. I actually used {{Screen reader-only}} within the scarf template to generate the snippet that gets read, so glad I'm using it correctly – was slightly concerned this was too much of a fudge/wasn't applied correctly. Not surprised you've not come across the scarf template, it's used on very niche subset of articles! Time to write some more descriptions... (cf Academic scarf) Charlie A. (talk) 09:13, 14 May 2022 (UTC)

Emojis do not display in some Chrome browsers

While searching wikipedia for a strange blank box character appearing on some web pages, I saw that the Emoji page was not rendering all the emojis on Google Chrome (apparently a known deficiency). I then added this to the talk page:

== Emojis do not display in some Chrome browsers ==

In the section "Emoji versus text presentation", Google Chrome on Windows 8 renders the first emoji character as a blank box. In Firefox it renders as expected. Should Wikipedia add an image to avoid confounding the reader? I.e., should wikipedia pages be accessible to the widest variety of users, and not merely those with the latest versions of browsers and operating systems? -84user (talk) 12:11, 18 June 2022 (UTC)

-84user (talk) 12:33, 18 June 2022 (UTC)

@84user: it's annoying that emojis aren't universal across browsers and operating systems; however, we do have MOS:ICON, which "encompasses any small images – including logos, crests, coats of arms, seals, flags – or other decoration, whether produced by small image files, typographic dingbats, emojis, or CSS display manipulation".

It's typically good practice to use emojis, and any other icons, as sparingly as possible for reasons of display and accessibility. As far as I know, emojis themselves aren't considered suitable for use in article text unless it's unavoidable, and they're covered under MOS:ICON.--Ineffablebookkeeper (talk) ({{ping}} me!) 13:23, 18 June 2022 (UTC)

What gets displayed (or read out by screen readers) will depend upon several factors, such as: the operating system; installed fonts; the browser and version. For example, the small red rose in my sig displays in three different ways on my two PCs and my mother's laptop, all using Firefox but different versions of Windows. Opera just shows a blank rectangle.

One advantage of emojis over images is size. The one in my signature occupies just seven bytes, I know of none that exceed ten. PNG images, on the other hand, will be a minimum of 69 bytes - and that's for just one pixel. --Redrose64 🌹 (talk) 20:26, 18 June 2022 (UTC)

discussion at Template talk:Fraction

There's a discussion at Template talk:Fraction#Fractions are not readable with screen readers or virtual assistants. KaraLG84 (talk) 13:01, 14 July 2022 (UTC)

Module:RoundN background colors

A discussion was started at Module talk:RoundN § Medal colors for gold/silver/bronze, aiming to change the module's background colors in favor of more accessible ones. Please, join us in it, as we lack experience in the subject. CLalgo (talk) 13:22, 18 July 2022 (UTC)

Question about how screen readers handle List of presidents of the United States

Hi, a question came up at the FLC for List of presidents of the United States. Specifically, several of the cells in the table use "----" (which results in a horizontal line) as a separator between multiple items in a single cell, such as if a single president had two terms, then the "election" column has two items separated by that line. Can anyone tell us how screen readers handle these cells? Is it intelligible? Thanks! --PresN 18:01, 30 July 2022 (UTC)

I've replied there. Graham87 03:20, 31 July 2022 (UTC)

Template grc-transl

I just came across {{grc-transl}}, which takes Ancient Greek text and gives an automatic transliteration. However, I'm not sure if this actually encodes the relevant text with a language tag like {{lang}}, or doesn't, like {{Script/Hebrew}}.

I'd appreciate if someone could check, though I'm not entirely sure the template itself needs to exist...would be nice to see this function rolled into {{lang}} or something.--Ineffablebookkeeper (talk) ({{ping}} me!) 10:10, 15 August 2022 (UTC)

The first on the list at Special:WhatLinksHere/Template:Grc-transl is Anatomy, in which I find {{grc-transl|ἀνατομή}} → anatomḗ and the final HTML for that is <span title="Ancient Greek transliteration" lang="grc-Latn"><i>anatomḗ</i></span>. Whilst grc-Latn is probably intended to indicate ancient Greek written in Latin script, it's not a valid ISO 639-3 code. --Redrose64 🌹 (talk) 06:41, 16 August 2022 (UTC)

The lang attribute takes a BCP 47 value (see MDN), and grc-Latn is correct for Ancient Greek in Latin script (checked with this tool). the wub "?!" 09:41, 16 August 2022 (UTC)

How does Template:Title language handle transliterated text?

I've been wondering this for a while – {{Title language}} will encode an article title in its ISO language code, but I don't know how it handles transliterated text. I'd appreciate, once again, someone with more knowledge having a gander at it.

(I'm also not sure how it handles titles where only part of the text needs a language tag; it only has two parameters at present, one for a language code and one to set italics. If there's no present options to handle this, then it feels like a loophole that needs closing.)--Ineffablebookkeeper (talk) ({{ping}} me!) 11:14, 29 August 2022 (UTC)

About merged cells in table

I was recently highlighted to accessibility issues with regards to merged cells in tables, particularly with regards to WP:DTT. I like to ask, using a similar example, Jordan Chan#Film and television, the filmography table contain merged cells for the year. It was deemed not accessible to screen readers and using this example, to unmerge and listing each year individually for each row. In terms of accessibility, should the years be left unmerged?

I searched the archive but what I found is about more complex tables with nothing on this common merging of years. If I had misread or missed out, appreciate if someone can point me to the correct archive for my question. Thanks! Justanothersgwikieditor (talk) 01:41, 20 September 2022 (UTC)

@Justanothersgwikieditor: Merged cells like this aren't a problem for screen reader users. I see that at User talk:Justanothersgwikieditor/Archive 2#Do not merge cells, Treysand mistakenly cited this section of the data tables tutorial (which is not a guideline), but that section refers to tables *within* tables (i.e. two table tags inside each other in the HTML), not row/colspans, as clearly described at the cited source. Graham87 06:44, 20 September 2022 (UTC)

@Graham87 : Thank you for your explanation but I must admit that initially I missed out the section linked by Treysand and my understanding of nested tables to be quite different. Hence I am asking for clarification here. Once again, thanks! Justanothersgwikieditor (talk) 06:57, 20 September 2022 (UTC)

@Justanothersgwikieditor: Take it from me - if Graham87 says there is no problem, you can rest assured on that 100%. --Redrose64 🌹 (talk) 20:12, 20 September 2022 (UTC)

Discussion of Strong template on its talk page

There is a continuation of the discussion of the proper usage of the Strong template with respect to the Lead section and the name and aliases of the article subject. A change was made to the documentation today that a) removed the instruction on how and why to use it and b) made a note that there is no consensus to use it in the Lead, with a citation.

I think the lack of widespread usage of this template, and the Em template, may have something to do with it not being in the MOS examples when it should be used, eg. MOS:LEAD. It's not enough to make a comment in the template documentation. If this is an accessibility issue, and it is, then using it should be a clear yes. However, I used it recently in a Lead of an article I have been working with, and a long-time editor removed that change. – Elizabeth (Eewilson) (tag or ping me) (talk) 14:53, 10 November 2022 (UTC)

@Eewilson: I've left a comment over there. You're right; leaving a brief comment on accessibility on a template's documentation is useless if it's all but an orphan, with no mentions of its apparent importance in the Very Big Very Important Please Look Here Manuals of Style we have. Who's going to discover such templates frequently enough to make that worthwhile? Only editors digging around in the Template undergrowth are going to discover them that way.—Ineffablebookkeeper (talk) ({{ping}} me!) 17:11, 10 November 2022 (UTC)

New calendar template

Calendar for year with 1 January on a Monday

2024
Date					Sep	Jan	Oct	May	Feb	Mar	Jun
					Dec	Apr			Aug	Nov
						Jul
1	8	15	22	29	Sun	Mon	Tue	Wed	Thu	Fri	Sat
2	9	16	23	30	Mon	Tue	Wed	Thu	Fri	Sat	Sun
3	10	17	24	31	Tue	Wed	Thu	Fri	Sat	Sun	Mon
4	11	18	25		Wed	Thu	Fri	Sat	Sun	Mon	Tue
5	12	19	26		Thu	Fri	Sat	Sun	Mon	Tue	Wed
6	13	20	27		Fri	Sat	Sun	Mon	Tue	Wed	Thu
7	14	21	28		Sat	Sun	Mon	Tue	Wed	Thu	Fri

The above calendar-table is produced by {{One page calendar}}, which I have just published (the template will generate a calendar for any Gregorian year). How would you improve its accessibility? Feel free to edit the Lua module directly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:47, 11 November 2022 (UTC)

I can't make head or tail of it on either JAWS or NVDA ... and I honestly have no idea how to even start making it more intuitive for screen reader users, if that's even possible (my HTML table knowledge is about a 2 out of 10 and my lua knowledge is about a 0.002). The unusual month order is a problem, for a start, let alone trying to figure out what the columns and rows mean. I'm obsessed with calendars to the point that I once wrote date calculation functions in the JAWS Scripting Language, for which it is absolutely not designed, and even *I* can't understand this template. My friend Codeofdusk, who's also blind, can't either; he told me that he just doesn't have the spacial reasoning skills to process it. I'm just not sure that a one-page calendar is really the best idea for general use; {{Calendar}} is perfectly accessible. Graham87 03:22, 12 November 2022 (UTC)

"Click" versus "select" in technical writing

Users with disabilities have different options for interacting with a user interface. They can use a mouse device, trackpad, touchscreen, voice, and possibly more. Because the word "click" is traditionally associated with a mouse, some technical writing style guides now say that "click" should be used only for mouse devices, while a more generic word such as "select" should be used if the device is not known. For example, assuming that users have different ways to interact with a program, we could ask users to "select" a button, menu item, or keyboard key. A substantial effort would be required to revise documentation in this way. The question is: Will this effort bring significant value to users? Do users with disabilities want to see "click" replaced with "select"? 2600:8800:7109:1500:81D0:8BA1:BCA6:46FB (talk) 22:06, 28 November 2022 (UTC)

Speaking only for myself, I think it's a relatively minor issue. Graham87 06:04, 29 November 2022 (UTC)

Is Template:switcher WCAG-friendly?

I was wondering, whether {{switcher}}'s use on Tennis Masters page causes any issues with screen readers. Qwerty284651 (talk) 18:28, 10 December 2022 (UTC)

It's fine with screen readers because it's just a standard radio button. I didn't know that was even possible with wikitext, though. Graham87 03:23, 11 December 2022 (UTC)

Yes, it's possible with wikitext. See here. Note: the two parameters data-switcher-label-style and data-switcher-top-choices listed in the "Testing nee features" subsection are not in the live gadget code at MediaWiki:Gadget-switcher.js so they cannot affect the gadget. Don't know how much this info is useful, but decided to share it anyway, in case you planned on using it. Qwerty284651 (talk) 03:47, 11 December 2022 (UTC)

There is a related discussion at Template talk:Switcher#TOC not working with switcher with subsections. --Redrose64 🌹 (talk) 09:36, 11 December 2022 (UTC)

@Redrose64, I am the one who started that discussion.Qwerty284651 (talk) 14:30, 11 December 2022 (UTC)

Wikipedia:Mobile communication bugs listed at Requested moves

A requested move discussion has been initiated for Wikipedia:Mobile communication bugs to be moved to Wikipedia:Communication bugs. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 19:49, 16 January 2023 (UTC)

To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject.

Non-Scrolling Sidebar

Wikipedia now uses a non-scrolling sidebar, which can trigger motion sickness and migraines if users scroll. If users have already blocked "smooth" scrolling, some workarounds are to 1. only navigate using page down, and/or 2. in Firefox or a few other browsers, reduce the frame rate; since Firefox prefs also use a non-scrolling sidebar, they ose the same problem. I think *if* Wikipedia is going to use a non-scrolling sidebar, then rather than requiring users to avoid the mouse and/or adjust browser settings, it should have an easily-discoverable button to hide the sidebar, which does not use its own animation when hiding or showing the sidebar. 173.73.0.102 (talk) 21:38, 20 January 2023 (UTC)

P.S. Even at only 1 frame/second, it can be disorienting. 173.73.0.102 (talk) 21:50, 20 January 2023 (UTC)

P.P.S. Okay, it has the hide button. Even so, it can cause severe motion sickness *before* people notice that it won't scroll and needs to be hidden. 173.73.0.102 (talk) 21:59, 20 January 2023 (UTC)

The hide button doesn't work in eink-browser. 173.73.0.102 (talk) 04:37, 23 January 2023 (UTC)

Let's remove "disorder" language

Hi. I noticed there are plently of templates with the label "disorder". I strongly suggest editing those templates to remove such label. For example, instead of "bipolar disorder" it should read only "bipolar". "Borderline personatiy disorder" should be "borderline personality". And so on.

Psychiatry tends to categorize as disorder anything that it doesn't like, ignoring the likelihood that they are not disorders at all but different ways that the brain has to work. Also, Psychiatric diagnosis many times are completely unscientific and tend to do a lot of harm to some people in their self-esteem, career, social life, and even desire to live.

You can check the article Neurodiversity and Psychiatric survivors movement for more context. Regards, Thinker78 (talk) 16:50, 24 January 2023 (UTC)

References

Recent Article layout changes make navigation very slow for visually impaired using screen magnification!

Tracked in Phabricator
Task T328480

I have used assistive tech (text-to-speech screen reading and screen nagnification) for over 25 years. Wikipedia articles appear to have been reformatted such that the Contents panel (that typically formerly appeared after the headline article summary) has disappeared. As a severely visually impaired user (registered Blind in the UK in 1995) I have used my residual vision to quickly find the article section of interest. All articles I have accessed in the past week (since late January 2023) omit the Contents panel and hence either require me to scroll through the article or instigate a search to possibly find where my interest lies. This is very inefficient when having to use x5 magnification on a 24" screen! In the words of UK's 'Points Of View'.... "Why, oh why....?" did you have to break something that did not need fixing?....IMHO, of course.

Please bring back the shortcut-embedded Contents panel!

Sincerely,

PVR. 31/01/2023 86.20.143.27 (talk) 10:29, 31 January 2023 (UTC)

This is the new :Vector 2022 skin. There are instructions for going back to the old skin in the above link. If you'd like an account so you can go back to the old look, you can email me at grahamwpgmail.com and I can help set one up for you (and help you bypass all the CAPTCHAs. It does indeed have a new table of contents but I have no sight at all and don't used the skin so I don't know how to help you use it. Graham87 15:24, 31 January 2023 (UTC)

Hi, PVR! I'd suggest creating an account so that you can switch to the old skin and save that preference; Graham87 has given the instructions above. If you don't want to create an account, however, the Table of Contents is hidden inside a pop-up that can be opened using a hamburger button next to the page title. This is the case for screens smaller than 1000 pixels post-scaling (that is, after the page has been resized due to zoom). It seems that the accessibility of this has been questioned in the past, but no concrete solution has been found as of now. I'll copy over your message to the related issue report to give it more visibility, both to other users and to the Wikimedia Foundation employees working on the new skin. Chlod (say hi!) 17:54, 31 January 2023 (UTC)

On second glance, the linked task might only be related, not exactly the root of the issue. I'll see if this warrants a new task (should no other task for this exist) and update accordingly. Chlod (say hi!) 18:05, 31 January 2023 (UTC)

I've created this Phabricator task to investigate and track this specific issue. Feel free to leave comments there, especially with your (i.e. anyone reading this') experiences with the new table of contents. Chlod (say hi!) 18:48, 31 January 2023 (UTC)

I've just had more of a play with this using the information in the Phabricator task up above with JAWS and NVDA. In JAWS the button to get to the table of contents is called "Unlabelled button 0" and in NVDA it's read out as "Menu button". This is not exactly ideal. Graham87 02:18, 1 February 2023 (UTC)

Thanks for filling that task and testing this out! I've sent a response in phab saying the same thing, but the missing label is definitely a regression and we will be fixing that soon. I also mentioned a few related tasks (i.e. adding a notice when the ToC is moved, ensuring the ToC is always accessible via navigation region) that the team would like to implement that should help with the concerns brought up here. Let me know if you have any other questions! BWang (WMF) (talk) 16:32, 3 February 2023 (UTC)

More Realistic Text to Speech - TorToiSe

Recently an open source text-to-speech engine called TorToiSe was released -- repo here -- that has much more realistic prosody (pacing, intonation) than previous TTS. The main downside is it is more computationally intensive to create recordings, about maybe four to eight hours per article on a midrange ($500-1000) GPU. I've been toying around with it, having it read Wikipedia articles, which you can listen to here as a podcast RSS feed of mp3 files. As part of that I've also been working with a few python text processing libraries to "normalize" the speech, that is, to make it easier for a TTS engine to read it without mistakes, which you can see at this github repo. The repo also has scripts to facilitate setting up a system to have TorToiSe read them. That is still a work in progress that I'm chipping away at when I have time. I just wanted to mention it someplace wikipedia-ish in case it is of interest to anyone, and to point others to it as something to be thinking about. At right this moment, TorToiSE seems to be at a sort of an odd place significantly beyond the fast-but-robotic TTS of the past, but not quite 100% to the point of a human. It seems easy to imagine, though, that in the coming years it, or something like it, could be used to generate placeholder audio files for the many unfulfilled Spoken Wikipedia Requests, until they can be read by a human. James Betker, the guy who wrote TorToiSe as a hobby is now working at OpenAI, so likely at some point there will be a more refined (and hopefully faster, and still open-source) version out in the world. xenotrope (talk) 06:51, 3 February 2023 (UTC)

Are you familiar with Wikispeech ? User:Sebastian Berlin (WMSE) knows quite a bit about it and might have some interest. —TheDJ (talk • contribs) 12:24, 3 February 2023 (UTC)

Thanks for the info (and the ping). Something to keep an eye on for Wikispeech. Hopefully we can add it as a TTS engine when it's fast enough. Sebastian Berlin (WMSE) (talk) 14:20, 3 February 2023 (UTC)

Is there a working demo for Wikispeech? I did look at it a few days ago, and again today. Just seems to be a single demo page that said "Could not load audio" when I clicked play. xenotrope (talk) 22:44, 3 February 2023 (UTC)

HTML tags like ins

I've just come across the <ins> tag; WP:REDACT states that "Any inserted text should be marked with <ins>...</ins>, which renders in most browsers as underlined text, e.g., inserted".

Does the text read out in a screenreader as having been inserted? Or is it relying on the presence of a visual underline, with no semantic features, to communicate that text has been inserted?—Ineffablebookkeeper (talk) ({{ping}} me!) 20:12, 31 January 2023 (UTC)

@Ineffablebookkeeper: The <ins>...</ins> and <del>...</del> tags have been part of HTML since HTML 4.0 (they were proposed for HTML 3.0 but didn't make it into the HTML 3.2 specification), which means that they have been supported by browsers for over 25 years. The present HTML 5.2 spec may be found at either W3C Recommendation, section 4.6 or WhatWG HTML Living Standard, section 4.7.

Compared to non-semantic purely visual methods like underline and strikethrough, there are at least two benefits to using the ins and del elements: (i) they have semantic meaning - screen readers will call them out as insertions and deletions; (ii) they may enclose block elements such as lists and tables. They are, in fact, the only HTML elements which may both enclose block elements and be enclosed by inline elements. --Redrose64 🌹 (talk) 22:37, 31 January 2023 (UTC)

Both the main Windows screen readers, JAWS and NVDA, now support reading out ins/del elements. Graham87 02:26, 1 February 2023 (UTC)

It's also supported by VoiceOver/Safari on iOS (but not on macOS yet) —TheDJ (talk • contribs) 12:32, 3 February 2023 (UTC)

Good to know all of this; I might add this to MOS:ACCESS and the relevant wikiguides that mention these tags. Thanks!—Ineffablebookkeeper (talk) ({{ping}} me!) 11:18, 4 February 2023 (UTC)

My personal Wikipedia timeline

I've made a personal timeline of my Wikipedia activities, which might interest some editors here because I've written about the various accessibility challenges I've had on this site over the years, among other things. Graham87 12:51, 13 February 2023 (UTC)

Your suspicions were correct. Merci, amigo. ―Justin (koavf)❤T☮C☺M☯ 19:44, 13 February 2023 (UTC)

I've only read down to the bottom of the "Early technology access and encyclopedic experiences" section, but it's a pretty good read so far. --Redrose64 🌹 (talk) 12:03, 14 February 2023 (UTC)

Thank you Graham. That's very insightful and what a great idea to write something like this down ! —TheDJ (talk • contribs) 13:21, 14 February 2023 (UTC)

Wikipedia is now blocking Lynx

Lynx (web browser) is a browser used by blind people. In March 2023 I found I can no longer read Wikipedia with Lynx because somebody has configured Wikipedia servers to hang indefinitely on any browser connection that identifies itself as Lynx, probably because they were given mistaken advice that Lynx is a hacking tool or something. I have to set my browser to lie about what it is, which is not good practice and it makes me feel guilty about lying. Could somebody please look into this and consider unblocking the Lynx browser for accessibility, many thanks. 80.44.31.71 (talk) 08:40, 2 March 2023 (UTC)

I don't know of a single blind person who uses Lynx these days. They all use modern browsers. It's not even mentioned in the latest this screen reader survey by WebAIM. Graham87 15:05, 2 March 2023 (UTC)

I use Lynx. WebAIM's survey is quite small and likely has a US bias. They also chose to group a bunch of browsers into an "Other" category instead of listing them. 80.44.31.71 (talk) 00:22, 3 March 2023 (UTC)

Hi IP — I've just navigated to this page using Lynx (2.9.0dev.6, SSL-MM 1.4.1), so it doesn't appear to be an issue targeting Lynx at the very least.. — TheresNoTime (talk • they/them) 15:10, 2 March 2023 (UTC)

it's working for me again now as well. Maybe they fixed it, thanks 80.44.31.71 (talk) 00:22, 3 March 2023 (UTC)

Problem with text to speech

I use Microsoft Edge, and it has a text to speech option to read me articles, but it keeps mentioning the numbers of the sources, which is really irritating. I hope someone can help me here, since this is probably a problem for people with disabilities too. I would be grateful for a solution :) Ramka8707 (talk) 14:49, 2 March 2023 (UTC)

@Ramka8707: To remove the footnote numbers you can use User:Zhaofeng Li/RefToggle. Most blind people would get used to the footnote numbers. Graham87 15:28, 2 March 2023 (UTC)

Honestly, it is quite shocking to me that people with disabilities have to deal with this stuff. Can I somehow escalate this to a higher authority that could potentially change the footnote problem? Thanks for your help so far :) Ramka8707 (talk) 16:49, 2 March 2023 (UTC)

@Ramka8707: I guess so ... see How to report a bug ... but whether it will be acted upon is another matter entirely. Blind people have as much of a right to follow footnotes as anyone else. Most of us use screen readers, which give far more control over how text is spoken/output to a refreshable Braille display than any browser's in-built text-to-speech feature ever could. Graham87 01:14, 3 March 2023 (UTC)

Of course blind people have a right to follow footnotes, never said they don't, but when it comes to accessibility it would really be a great feature, if one could simply deactivate the footnotes in order to let text to speech operate, no? Thank you for the link :) Ramka8707 (talk) 07:45, 3 March 2023 (UTC)

To operate effectively on the web and life in general, blind people and heavy text-to-speech users have to get used to way more than the occasional errant number. Graham87 13:57, 3 March 2023 (UTC)

You are quite right, but we got to enact change wherever we can, right? Anyway, don't want to tie you down with my silly war here. Thank you again for the help you have given me. I am kind of new, so it feels really cool to have such good help straight away :) Ramka8707 (talk) 22:55, 3 March 2023 (UTC)

@Ramka8707: The MediaWiki software (which is what converts Wiki-markup into usable web pages) does its best to produce web pages that comply with the published recommendations for HTML. The web browser vendors should be writing their browsers in such a way that web pages are presented in a predictable manner according to those same standards, but they don't always do so. Microsoft are notorious for deviating from some of the practices that other browser vendors follow reliably. Sometimes the MediaWiki software will reluctantly introduce adjustments to handle browser quirks, and it can be a real nightmare for the developers to keep up to date with changes in published recommendations and changes in browser behaviour (there are many available most of which change several times a year), as well as ensuring that accessibility aids behave as they should. Third-party add-ons similarly need to keep up with the latest changes, but they can give a more satisfactory experience than a browser's inbuilt features.

The numbers in square brackets that are also linked and superscripted are, as far as web browsers are concerned, exactly that - they have no special meaning; they are just links to another part of the same page. Browsers don't know what references are, but they do know how to handle links; and to permit a link to be followed, they need to present the text within the link, and to distinguish one of these links from another, the MediaWiki software uses numbers.

If you really want to suppress all of the superscripted linked numbers in square brackets, you can do this by placing this CSS rule

sup.reference { display: none; }

into Special:MyPage/common.css and saving it. However, this means that you will also suppress the links to the article's sources, although the sources will still appear elsewhere on the page. --Redrose64 🌹 (talk) 22:01, 3 March 2023 (UTC)

You're completely right about your points. As someone who is sighted, I'm contemplating how easily individuals with disabilities or their family members can access the information you've shared to improve their Wikipedia experience. Have you ever considered why there isn't a readily available "FAQ" with the essential resources? You and I are aware that most people tend to leave after a few clicks, since they haven't learned to navigate this space effectively. I appreciate the work you do, but I'm slightly frustrated (which isn't your fault, I know you do great work, I saw your account). Ramka8707 (talk) 23:20, 3 March 2023 (UTC)

Also this question was first posted at the teahouse. Graham87 01:21, 3 March 2023 (UTC)

Accessibility specifically in editing Wikipedia?

Are there any resources, where I can learn about accessibility issues specifically for users who edit Wikipedia? For example, do some users have trouble using source editing vs. WYSIWYG editing, the Preview button, or edit summaries? What do I, as a Wikipedia editor, need to know about the challenges that my comrades might face? Mgnbar (talk) 22:21, 20 March 2023 (UTC)

There's a bit at m:WikiBlind User Group#Getting started as a blind editor which I helped out with. Graham87 07:53, 21 March 2023 (UTC)

Colons and asterisks

FYI

 – Pointer to relevant discussion elsewhere.

There is a post at Wikipedia talk:Colons and asterisks#Counterpoint that could do with a well-thought-out response. --Redrose64 🌹 (talk) 22:19, 31 March 2023 (UTC)

Add accessibility metadata to the Date template

See my post at the bottom Template_talk:Date#Make the date template emit time metadata, ensuring asscessability and allowing people to view dates in their perferred format.. — Preceding unsigned comment added by MatthewUtzig (talk • contribs) 23:35, 7 April 2023 (UTC)

Is the emphasis template used for species/genus nomenclature?

Came across the use of {{em}} to replace italics around the scientific name for a plant species in an article (specifically Kali tragus); this is the first time I've seen it. To my mind, I wouldn't have thought of the italics used around a genus name as emphasis. Is such usage warranted?—Ineffablebookkeeper (talk) ({{ping}} me!) 10:31, 10 May 2023 (UTC)

@Ineffablebookkeeper: no. It's the convention here to use italics for the scientific names of organisms at the rank of genus and below. Absolutely not emphasis. Peter coxhead (talk) 15:01, 10 May 2023 (UTC)

I wouldn't say so, no. Graham87 15:12, 10 May 2023 (UTC)

Thanks for the advice. I think the template documentation mentions something about this, so I'll update it.—Ineffablebookkeeper (talk) ({{ping}} me!) 18:59, 10 May 2023 (UTC)

Strobing Animations

Some wikipedia articles include non-stop autoplaying gifs and/or pngs. It's usually posible to configure desktop browsers to block these. But it's not always possible to configure tablet browsers to block these.

I often use eink due to neuro issues, and with text and static images it helps, but unless I set a blurry "a2" display mode, with animation it starts rapidly flashing between white and black.

The current MOS is inadequate (and feels insulting) because it permits animations if they're no longer than 5 seconds (which is far too long) or or if they have control functions to turn them off (which may not be visible and/or operable in the middle of the blinding pain if you are even mildly affected).173.73.0.102 (talk) 06:23, 6 March 2023 (UTC)

This is (or should be) covered by MOS:ANIMATION. --Redrose64 🌹 (talk) 19:41, 6 March 2023 (UTC)

User has now raised the issue at Wikipedia talk:Manual of Style/Accessibility#Animations Aren't Safe, Especially on E-Ink. --Redrose64 🌹 (talk) 14:54, 13 March 2023 (UTC)

So is there anything I can do to tag these images for replacement? 173.73.0.102 (talk) 02:37, 12 May 2023 (UTC)

“it starts rapidly flashing between white and black.” I interpret this as “the technology used makes animations even worse” and thus it is not a fundamental content issue. I think animation removal will anger people, I think replacement is not going to happen (labor isn’t free), I think there are no programmers to fix it technology wise (again labor isn’t free) and thus I don’t see a quick solution. I’m not saying your problems aren’t real, but I see no way I personally or most other editors can realistically fix this shortcoming of e-ink displays. —TheDJ (talk • contribs) 08:19, 13 May 2023 (UTC)

This is a bit of a "throw out the baby with the bathwater" approach, but until someone comes up with something better you can use css to hide all gifs. Edit your common.css file and add the following:

img[src$=".gif"] {

display:none;

}

No guarantees that this will work in all cases, but I tried it on a few articles with good results. The downside is that it hides all gifs and you don't even see that there is supposed to be a gif there. -- Random person no 362478479 (talk) 16:19, 24 May 2023 (UTC)

And you need an account and have to be logged in to use this method. -- Random person no 362478479 (talk) 19:52, 24 May 2023 (UTC)

Extinct template versus just †?

Is the {{Extinct}} template (which produces †) more semantically meaningful than †, or are the two the same screenreader-wise?—Ineffablebookkeeper (talk) ({{ping}} me!) 17:17, 16 June 2023 (UTC)

No, they are not the same. The {{extinct}} template emits the following HTML:

<abbr title="Extinct" aria-label="Extinct" style="border: none; text-decoration: none; cursor: inherit; font-weight: normal; font-style: normal;">†</abbr>

- some screen reader software will pick up that title= attribute. --Redrose64 🌹 (talk) 21:25, 16 June 2023 (UTC)

@Redrose64: Thank you!—Ineffablebookkeeper (talk) ({{ping}} me!) 10:40, 17 June 2023 (UTC)

Discussion at Template talk:WikiProject banner shell § How project banners should look

 You are invited to join the discussion at Template talk:WikiProject banner shell § How project banners should look. DFlhb (talk) 17:42, 7 July 2023 (UTC)

Especially interested in your feedback regarding the colours, specifically this design. DFlhb (talk) 17:42, 7 July 2023 (UTC)

Note that there is now an RfC on the matter, which everyone here is invited to. DFlhb (talk) 19:28, 9 July 2023 (UTC)

• Here's the link to the RfC mentioned above: Template talk:WikiProject banner shell#RFC. - 47thPennVols (talk) 22:01, 9 July 2023 (UTC)

Help Desk question about screen reader

Someone posted at the help desk about problems they are having accessing Wikipedia using a screen reader: Wikipedia:Help_desk#Lack_of_Access. Maybe someone here has relevant expertise? -- Random person no 362478479 (talk) 19:36, 12 July 2023 (UTC)

I replied there a little earlier before noticing this message. Graham87 05:49, 13 July 2023 (UTC)

Flashing image

So (Warning re: epilepsy) autostereogram has a rapidly flashing image on it right at the top of page. Yeah. I don't have epilepsy, but I was still shocked by that thing just starting to animate outta nowhere when randomly navigating there.

I suspect an IP deleting content might provoke a revert from an overly enthusiastic vandalism patroller so hopefully someone doesn't mind doing the needful. Might also not hurt to put some kind of note or editnotice about animations and link to the accessibility guidelines since that's a page that will always attract well-meaning but unaware people looking to add animated content there for visualizing the effect. 47.155.41.201 (talk) 08:44, 6 August 2023 (UTC)

Template:IPA vowels/accessible

FYI

 – Pointer to relevant discussion elsewhere.

Regarding Wikipedia talk:Manual of Style/Accessibility/Archive 14#Template:IPA vowels: Template:IPA vowels/accessible has been sent to TfD. The discussion is at Wikipedia:Templates for discussion/Log/2023 August 7#Template:IPA vowels/accessible. --Redrose64 🌹 (talk) 18:29, 7 August 2023 (UTC)

Fractions in category names

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Dates and numbers#Fractions in category names. --Redrose64 🌹 (talk) 20:43, 12 August 2023 (UTC)

Dispute at WP:DRN

I am mediating a content dispute at DRN concerning the display of the scores of football. One of the issues is that one of the editors states that some of the templates that are being used to display club seasons does not comply with the accessibility guidelines. Here is how I am asking for assistance from this project. I would like to request an experienced editor to look at the dispute, and either say that some of the templates that we are using are not access-compliant, or that the templates that we are using do satisfy the accessibility guidelines. The editors with the accessibility issue can come to this project page and present their cases, or it would be useful if an experienced editor who is familiar with accessibility joined in the discussion at DRN. Thank you in advance for any help you can give. Robert McClenon (talk) 05:23, 22 September 2023 (UTC)

Discussion about MOS:ACCESS at GAN talk

I've started a discussion about incorporating (parts of) MOS:ACCESS into GACR at the GAN talk page. Best, voorts (talk/contributions) 16:20, 24 September 2023 (UTC)

Table column in The X Factor article which only conveys information using colour

I started a discussion at Talk:The X Factor#Table under "The X Factor around the world" is not accessible to screen reader users. As the talk page seems pretty dormant and I have had no replies, I thought I'd mention it here to see what could be done about it if anything. KaraLG84 (talk) 21:23, 29 September 2023 (UTC)

Weird bug with JAWS/Chrome inserting misplaced spaces in output

See Template talk:Val#Screen reader problems with digits grouped by spaces in this template, in which I discover that the problem really isn't with that template at all but a JAWS/Chrome bug. There's nothing we can do about it here so this is just an FYI. Graham87 (talk) 11:40, 2 October 2023 (UTC)

Place topic headings right above where content begins

Moved from Wikipedia talk:WikiProject Accessibility/FAQ and common pitfalls

Graham87 (talk) 07:32, 8 November 2023 (UTC)

Visually impaired visitors need a heading at level 1 placed where content begins. On every Wikipedia page, there are a series of links, at best only remotely related, to the topic before the actual content begins. It forces visually impaired people to waste time arrowing around for each article's true beginning. 108.54.91.238 (talk) 21:16, 7 November 2023 (UTC)

As a fellow screen reader user, I can confirm that this indeed occurs with the new theme/skin, Vector 2022 because the heading is in a different position in the HTML (which better reflects how sighted people see the page). The easiest way to get around this is to press a key to move to the next block of non-link text (usually n) after going to the first-level heading. However, if you want the old Wikipedia look back, I can create an account for you and help you revert to an older Wikipedia skin. If this is what you would like, email me at grahamwp@gmail.com and I can take it from there. Graham87 (talk) 07:32, 8 November 2023 (UTC)

Low vision, but not blind

I just read this wikiproject page and perused the talk page. Are there guidelines for formatting to accommodate users who might have low vision issues (not actually blind, and not using any accommodative technology)?

I have poor eyesight (that's all I'm going to say on it) and, as examples, I like a lot of whitespace (glossary style rather than bulleted lists which present as walls of text), no unnecessary table formats (difficult to edit), and simpler images which show the subject (rather than 'busy' images which contain the subject but are hard to distinguish).

I haven't found any policies that suggest these ideas. Currently I'm dealing with swapping out images for better, simpler ones, but occasionally run into someone who wants to keep their favorite photos on display. A policy would be nice to support my changes.   ▶ I am Grorp ◀ 02:24, 12 November 2023 (UTC)

All that immediately comes to mind is having accessibility via CSS to increase font size and contrast and to use SVG where appropriate, so it can be infinitely magnified with no loss of clarity. It would probably be nice if we had collections of user scripts that enhance visibility... ―Justin (koavf)❤T☮C☺M☯ 02:28, 12 November 2023 (UTC)

Tool/Gadget for checking accessibility?

I'm curious if there is a Wikipedia-specific tool/gadget people can use to check a page's accessibility. I know other communities have specific tools/gadgets to make their jobs easier. For example, Did You Know...? (DYK), has something that with a single click analyzes the page for various factors to help determine eligibility for DYK. There's also the Edward Betts 'tool' for finding links to articles (often used to help orphaned articles) or check I'm wondering if there's something similar so users can quickly check the accessibility of a page and learn how to fix it, kind of like the "Check accessibility" feature in Microsoft Word. Significa liberdade (she/her) (talk) 20:44, 22 November 2023 (UTC)

I had the same question. I looked at https://webaim.org/projects/screenreadersurvey9/?hss_channel=tw-2382446636 and picked VoiceOver, as it was readily available to me. YMMV. RudolfoMD (talk) 09:07, 30 November 2023 (UTC)

Way to specify alt text for something other than an image (e.g. math)?

I came up with a great way to convey that a drug has a critical FDA-mandated black-box warning: the word "Warning" in a black box. See User:RudolfoMD/sandbox2. Great for sighted folks, that is. Is there a way to specify alt text for the math tag to be used or otherwise make the warning more accessible? Didn't find anything at Help:Displaying a formula; could use some guidance. I want to add this to so it appears in the infobox of hundreds of articles. T.I.A. RudolfoMD (talk) 09:18, 30 November 2023 (UTC)

Math has hidden MathML, which most screenreaders can handle and read out. And they will do that for this too. Please do not use math for decoration purposes. Just write a template with CSS styling. —TheDJ (talk • contribs) 10:21, 30 November 2023 (UTC)

Thanks. No clue how to do that (CSS styling), but I could try to figure it out or seek help. It was interesting to look at the source though, and gave me another idea.

The source that displays the math (in my browser) at its core is just an image with alt text. We could use the image and improve the alt text. Like <a href="/wiki/Boxed_warning">...<img src="https://wikimedia.riteme.site/api/rest_v1/media/math/render/svg/1735879add6c04cad562b5f3646d25a4ddf3d8bb" ... aria-hidden="true" ... alt="WARNING"></a>. I can do that. Seem reasonable?

(Also interesting that the image is an SVG containing alt text:

aria-labelledby="MathJax-SVG-1-Title">

<title id="MathJax-SVG-1-Title">{\displaystyle {\begin{array}{|}\hline W\!ARNING\\\hline \end{array}}}</title>

<defs aria-hidden="true">

I wonder if good internal alt text makes separate alt text unnecessary; I presume that's the idea. edit: Nah. Alt probably better for lynx. )

-R

The whole source (only possibly worth reading, and so collapsed and thus certainly not worth the effort of beautifully formatting it but wikignome Redrose64 did so anyway :-) ). (I wonder if a template exists/could be made to such problems without the use of the obscure syntaxhighlight thing. Seems like it; can't tell.)

<a href="/wiki/Boxed_warning" title=""><span class="mwe-math-element"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle {\begin{array}{|}\hline W\!ARNING\\\hline \end{array}}}"> <semantics> <mrow class="MJX-TeXAtom-ORD"> <mstyle displaystyle="true" scriptlevel="0"> <mrow class="MJX-TeXAtom-ORD"> <mtable columnalign="" rowspacing="4pt" columnspacing="1em" rowlines="" columnlines="" frame="solid"> <mtr> <mtd> <mi>W</mi> <mspace width="negativethinmathspace"></mspace> <mi>A</mi> <mi>R</mi> <mi>N</mi> <mi>I</mi> <mi>N</mi> <mi>G</mi> </mtd> </mtr> </mtable> </mrow> </mstyle> </mrow> <annotation encoding="application/x-tex">{\displaystyle {\begin{array}{|}\hline W\!ARNING\\\hline \end{array}}}</annotation> </semantics> </math></span><img src="https://wikimedia.riteme.site/api/rest_v1/media/math/render/svg/1735879add6c04cad562b5f3646d25a4ddf3d8bb" class="mwe-math-fallback-image-inline mw-invert" aria-hidden="true" style="vertical-align: -1.338ex; width:15.29ex; height:3.843ex;" alt="{\displaystyle {\begin{array}{|}\hline W\!ARNING\\\hline \end{array}}}"></span></a>

RudolfoMD (talk) 19:25, 30 November 2023 (UTC)

Figured out the CSS, I think. (Couldn't figure out the image method; wouldn't render right.) Edited Template:Drugboxwarns to use CSS.

Thus: WARNING.

:-)

RudolfoMD (talk) 06:50, 2 December 2023 (UTC)

References

Social impact of depersonalising language such as 'the colourblind'

Please tell me if this is in the wrong place. I live with a motor neurone disease but I am not defined by living with a motor neurone disease, I am defined by being a person. I was shocked upon reading the page on Colour blindness that within 5 lines of the start of the article the ableist social convention that defines people as their problem and not as people appears in the form 'the colorblind automatically develop...' These are people first and colour blindness is a secondary attribute, so we should always be aiming at modern best practice which is to use 'people who live with colour blindness...' or 'people who are colourblind...' or 'those who are...'. The section entitled 'Effects' starts 'A colorblind subject...' and in the same sentence has 'the colourblind...'. They are not scientific specimens as 'subject' suggests, nor are they a problem as 'the colourblind' suggests. These are living, breathing people not objects, so I am certain that there must be a place for this discussion but cannot find it and thus put it here. Please forgive me, I am English and have used colour throughout this paragraph, but absolutely accept the the American spelling, color, is acceptable throughout Wikipedia. DrRickZTTwo (talk) 11:59, 1 August 2023 (UTC)

This is a fine place to put this concern. That said, I'm confused: do you object to "The French have developed a long history of bread and cheese" or "Peruvians are proud of their Incan heritage"? ―Justin (koavf)❤T☮C☺M☯ 12:05, 1 August 2023 (UTC)

Thanks Justin, I am glad I got the correct location. I am quite certain that if French and Peruvian people object to being referred to thus, they will raise the issue. My concern is with those of us who live with disabilities and are defined by society as being a problem. I do not regard being French or Peruvian as being either a disability or a problem and thus both are perfectly acceptable. Does that distinction make sense? Personally I get called 'the afflicted', 'the disabled, and 'the sick', but I am first and foremost a person. It is difficult enough living with a disability without people treating you as though you have ceased to exist and become a problem. People who live with colour blindness undoubtedly live with a disability, but it does not define who they are, being merely one of a number of attributes that they, as a person, possess. Rick DrRickZTTwo (talk) 12:18, 1 August 2023 (UTC)

Sure, but 1.) by definition you won't hear from those who don't object and 2.) which qualities/properties/aspects of a person do you think can be adjectives in front of nouns and which ones not? ―Justin (koavf)❤T☮C☺M☯ 12:20, 1 August 2023 (UTC)

Thanks for this Justin, I suspect that the resources which you have listed below are going to be part of the answer to that question, but ultimately the answer is whether or not there is any social stigma which can be attached to such a word. I am the scientist, the biologist, the educator, the teacher and the unexpectedly successful artist, I am not the sick, the disabled, the autistic, the afflicted or the dying. It is a line which is drawn by social convention and social convention is decided by consensus through discussion, like this one. I am getting tired, so may have to come back to this later - my apologies. DrRickZTTwo (talk) 12:57, 1 August 2023 (UTC)

No worries, friend: we all sleep. Happy to have the conversation when/as you can. ―Justin (koavf)❤T☮C☺M☯ 13:00, 1 August 2023 (UTC)

Do you find this language issue to be a widespread problem in Wikipedia? Or is Color blindness the only example you have seen? If it's the latter, then the correct venue for discussion is Talk:Color blindness. But actually the best course of action is to Wikipedia:Be bold and edit Color blindness yourself.

I'm happy to edit it for you, but I do have one question: What about the phrase "colour-blind people" or "colourblind people"? Mgnbar (talk) 12:25, 1 August 2023 (UTC)

Oh, I see, from the materials that you've posted below, that "colour-blind people" is not sufficient to fix the issue. Thanks. Mgnbar (talk) 12:49, 1 August 2023 (UTC)

Thank you Mgnbar, both for your first question which is a good one and is going to require some research, and for getting to the resources that Justin posted before I did and answering your own question - much appreciated. I have used up what energy I have today, so will need to stop now, but will come back and, if you have not already edited it, edit the colour blindness page, once I have read the resources. I will also, probably fairly slowly, research other areas to see how widespread such language is. Thank you. DrRickZTTwo (talk) 13:04, 1 August 2023 (UTC)

I've made numerous edits to Color blindness, but there's still much to do, both on this issue and other issues in that article. Mgnbar (talk) 13:29, 1 August 2023 (UTC)

Thank you Mgnbar, I visited the page and you have already vastly improved it. Elsewhere I came across a welcome message (from 2012 - in another lifetime before Nortriptyline damaged my memory - now mostly fixed by many years of hard work, and the rare motor neurone disease with which I live turned my life upside down). It mentioned using four tildes in signing off on discussion pages. On this page it appears to have inserted the information on username and time automatically, perhaps because I initiated the discussion. Although having said that, inserting them here has automatically added them to the preview. DrRickZTTwo (talk) 00:56, 2 August 2023 (UTC)

Relevant parts of the Manual of Style:

• MOS:MEDLANG
• Wikipedia:Manual_of_Style/Psychology#Audience_and_language

Relevant discussions on the topic:

• Wikipedia_talk:Manual_of_Style/Archive_222#Person-first_language
• More

―Justin (koavf)❤T☮C☺M☯ 12:34, 1 August 2023 (UTC)

Thank you Justin, I shall work my way through these resources, and will also introduce my wife to them, because in life outside Wikipedia, she is a Bishop's advisor on Accessibility in a Diocese of the Church of England and there is no doubt that she can learn from the relevant parts of the Manual of Style and the Person-first_language archived discussion. She may also be able to contribute to the continuing evolution of the Manual of Style, if she chooses to become part of the Wikipedia team. Thank you once again for asking intelligent questions and for being so welcoming and kind. DrRickZTTwo (talk) 01:14, 2 August 2023 (UTC)

@DrRickZTTwo Thank you for bringing this up. After @Mgnbar made the changes this summer, I looked into this fascinating topic and learned a lot. My interpretation is: while motor neuron disease may fall better under the medical model of disability and therefore demand people-first language, colorblindness falls better under the social model of disability. To avoid the medicalization of colorblindness, I feel avoiding people-first language is the best option (for colorblindness specifically). Curran919 (talk) 22:53, 24 December 2023 (UTC)

Skip to talk and accessibility

Hello,

I always assumed the Template:Skip to talk was primarily for accessibility allowing screen readers to skip past heading content, however when I read the template page, no mention is made of accessibility, so I may very well be under false impressions. Not urgent, but clarification as to its role in accessibility might help the template page.  // Timothy :: talk  05:30, 10 January 2024 (UTC)

I'm not sure it's related to accessibility. I think it's just to skip long talk page preambles... like on this page. I get tired of scrolling down to get to the table of contents.   ▶ I am Grorp ◀ 06:17, 10 January 2024 (UTC)

Query re articles tagged with WikiProject Accessibility template

I noticed that there's a ton of articles tagged with this project's template. Considering this project deals with the accessibility of Wikipedia as a whole rather than improving disability related articles, I was wondering what the best thing to do about it is. KaraLG84 (talk) 00:35, 4 February 2024 (UTC)

This project was created in October 2007, long before the creation of WikiProject Disability in 2010, so the fact that we have articles under our scope is basically a historical artifact (ditto with the concept of this WikiProject, to be honest). To cut a long story short, the people who created this project were quite ambitious and are no longer here ... and I wasn't and am still not quite so keen but I'm still around. :-) WikiProjects as an institution are generally not doing too well these days; a cleanup could be done but I don't have a strong opinion on it. Graham87 (talk) 04:49, 4 February 2024 (UTC)