Wikipedia talk:WikiProject Accessibility

Jump to navigation Jump to search

Home breadcrumb.svg >Collaborations >WikiProjects >Accessibility

WikiProject Accessibility
WikiProject iconThis page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.
 

Scrolling of a template[edit]

Hey All We have a really long template which we added scrolling to. Concerns have been raised about accessibility for those who use voice commands. We also have significant attention from technical folks to solve any accessibility issues there might be.

Can you please detail any remaining issues here Template_talk:2019–20_coronavirus_pandemic_data#Scrolling? Thanks Doc James (talk · contribs · email) 23:48, 17 March 2020 (UTC)

Relevant discussion of table legends and MOS:COLOR[edit]

Feedback requested at Wikipedia_talk:Manual_of_Style#Typographical_symbols_used_for_notes_and_accessibility. Thanks. ―Justin (koavf)TCM 02:03, 21 March 2020 (UTC)

Review of introductory pages[edit]

Hi all! Myself and a few others have recently been working to develop the Help:Introduction tutorial series and the WP:Task Center to become better and more usable resources. They both employ a fair amount of non-standard formatting, so if anyone is interested, it might help to have someone here review them to see if there are any ways in which their accessibility might be improved. Cheers, Sdkb (talk) 07:15, 30 March 2020 (UTC)

Captions in tables dispute[edit]

FYI: Pointer to relevant discussion elsewhere.

Template talk:CBB yearly record start#Captions are necessary. It centres around these edits by Koavf (talk · contribs) that added a caption to a table, and the attempts by others to remove that caption. --Redrose64 🌹 (talk) 13:07, 6 April 2020 (UTC)

RfC started[edit]

I've now started an RfC to test consensus for expanding our guideline at MOS:DTAB to state that tables should always have a caption. The Rfc is at Wikipedia talk:Manual of Style/Accessibility #RfC on table captions. --RexxS (talk) 21:55, 6 April 2020 (UTC)

Another module tutorial with accessibility problems[edit]

Third module tutorial implemented despite our knowledge of them not holding readers because they cause so many different accessibility nightmares for many viewers....we should learn from our past mistakes not repeat them. But O well not all care about accessibility. Really need expert in coding to help here. We had an RfC that closed by votes of "I like it" over accessibility concerns raised by experience editors in the help field. Our main welcome temp now links to the Help:Introduction that does not work properly in mobile view....does not work with screen readers...or takes into account readers with no mouse (65 modules needed to get through it = having to press tab over 20 times per page to select relevant options ). Getting over 100 concerns from my Web accessibility evalution tool....not sure where to start here. Help would be great....the mob made the wrong choice or bad close (in my view) either way at least we could try to make it work as best we can.--Moxy 🍁 15:30, 7 April 2020 (UTC)

Moxy What page is the issue on? --Izno (talk) 15:36, 7 April 2020 (UTC)
see Help:Introduction to/All (edit to view sub pages). Wondering if we should split this in to mobile view and desktop view with Template:If mobile...very hard to code this for both in one format. Last time we did this format was with the Wikipedia Adventure... we never recovered the amount of new editors we lost last time we had module tutorial as many link.... Last thing we want is the loss of new editors happen again just because they can't read or complete the tutorial they are pointed two because of accessibility problems.--Moxy 🍁 15:51, 7 April 2020 (UTC)
@Moxy: I think it's a little disingenuous to imply that I don't care about accessibility, when my post about the Help:Introduction series is right above yours on this page. I came here because you kept talking about accessibility issues, although it should be noted that it was only you, not others as stated above. You seem to be the only one experiencing the issue in your screenshot on mobile — see the image I just added for my view. Still, we should figure out what it is that's causing issues on your device and fix it, since it's likely to be affecting some other readers, too, even if rare. {{u|Sdkb}}talk 17:23, 7 April 2020 (UTC)
Yes lots of it looks good votes...but not many aware of the problems we have had in the past that we are now repeating. Its why canvassing all over is very wrong.....now stuck fixing this over real work. Its really to bad our system works on votes and on real world application. --Moxy 🍁 19:07, 7 April 2020 (UTC)
I don't use mobile, and I generally leave such matters to people better informed. However the bad-screenshot appears to have an effective width of about 17 characters. That's generally one to three words per line. I'm not sure it's realistic to try to design for that resolution. I expect reading the tutorial would be about the least of the difficulties for anyone trying to edit at that resolution.
I of course have no objection if anyone does find a way to improve it, assuming they don't significantly negatively impact the the more usual page view. Alsee (talk) 11:41, 9 April 2020 (UTC)
Moxy It appears from your screenshot that you're forcing the desktop site on a mobile device. It looks bad, but so do a lot of pages if you do that, including Contributing to Wikipedia [1]. Sdkb's screenshot is representative of what is seen normally. the wub "?!" 20:44, 9 April 2020 (UTC)
Normal pages work normally for most in any platform. Yup...desktop on tablets is what millions do...also dont forget our screen readers, TV box and non mouse users. One day accessibility will be a policy till them all we can do is point out the problems and hope others listen.--Moxy 🍁 22:25, 9 April 2020 (UTC)

Alt text guidelines[edit]

I do not think I knew this WikiProject existed. Hi! I usually work at WP:Spaceflight. Sorry if I am rehashing a common topic or opening any old wounds.

A February 2019 RfC for requiring alt text in featured articles was closed as consensus against requiring the use of it. The primary argument was that our guidelines were insufficient to write good alt text. This is not intended to be a discussion to force FAs to use alt text, but instead a discussion on improving our guidelines to make it easier for anyone to write alt text. I know I have written poor alt text in the past and try to fix it when I find it.

We can move this discussion to the MOS page page at some point, but hoping to get wider input here.

How can we best determine that our guidelines are easy to understand and produce meaningful alt text?

We could rewrite the MOS page and we recruit editors who do not normally write alt text and see what they produce, and we could either perform an internal audit or seek an external audit to determine the quality of the alt text.

Other ideas? Should I just be bold on the edits I think would improve the guidelines and they can be reverted if they are a negative? I am happy to propose the specific changes as well, I think right now it is too text heavy and could be shorter but still convey the same information. This is something I have been half-ass working on for years, but it is all a bit overwhelming, and I am hoping to full-ass the work and collaborate on improving the MOS. Kees08 (Talk) 16:21, 7 April 2020 (UTC)

It's very hard to get people to understand why alt text is so important. We linked this years ago (outlines how easy it is to do) durring that debate to try to get others to understand....but to no avail.--Moxy 🍁 20:35, 7 April 2020 (UTC)
I think many believe it is important, but they do not prioritize it and that is what we can try to improve. My assumption for why they do not prioritize writing alt text is:
  • Confusing guidelines
  • No feedback
We can work on the first point by editing the MOS page guidelines we have. I am happy to take a crack at it, and if I do a poor job my edits can be reverted, but I hesitate to be bold on a guideline like that. I think it needs a lot of work so proposing changes can be done but would be very time consuming. If I could just propose changes I think would be contentious and boldly make the non-contentious edits (that I understand can be reverted), that would be most efficient.
We could add good alt text examples for highly-used infobox templates. See the examples I added to Template:Infobox spaceflight for insignia_alt and crew_photo_alt in TemplateData. Obviously this cannot be done with all alt text in infoboxes (see how I did not for the image_alt parameter), but there are cases where we could give specific examples relevant to thousands of images.
For the second point, a specific page to request feedback on alt text would be great. It could be advertised in the signpost.
Additionally, people that are confident in their alt text writing could offer to review and provide feedback on, for example, FACs that have existing alt text. We would have to be tactful in making sure it is not implied that we are attempting to override the consensus for not requiring alt text at FAC, but instead trying to improve alt text in the cases where it does exist.
These sorts of activities would improve users' confidence in adding useful alt text themselves. Does anyone have any other reasons why folks do not write alt text? Any thoughts to the ideas above? Happy to contribute and help where I can in this. Kees08 (Talk) 17:50, 9 April 2020 (UTC)
Although, after pondering on it a little more, those are the two points that I think need worked on, but has no actual research done to prove it. Before going through all that work, I am considering some sort of survey with questions such as 'How often do you use alt tags', 'summarize how you think alt text should be written', 'If you do not use alt tags, why (give a couple options and a freeform field)'etc. Has any work like that been done before on wiki? Kees08 (Talk) 19:01, 9 April 2020 (UTC)

@RexxS and Gog the Mild: Seeing if either of you have thoughts on the above. No rush, just wanted to get both of your feedback eventually. Kees08 (Talk) 19:07, 9 April 2020 (UTC)

Speaking just for myself, and as a relative newcomer, I find the current guidelines moderately clear. If others don't feel that. the way to go is BRD. Given that a group of three or more Wikipedians couldn't reach a consensus on when to break for a beer before the bar closed I suspect that the questionnaire option will be a lot of work for little return. But I could be wrong though and at the end of the day it's your call. Gog the Mild (talk) 19:17, 9 April 2020 (UTC)
@Kees08: The impression I get from years of encouraging the use of alt text is that editors in general don't realise the importance of alt text to screen reader users. I find very few editors who, having realised that importance, continue to deliberately omit alt text, and I'm unaware of anybody removing existing alt text.
On the other hand, explaining how to write alt text for Wikipedia articles is not a simple job. You are trying to get editors who don't have the experience of using a screen reader to imagine how an edit sounds to those using assistive technologies.
There is also a problem with referring editors to external guidance. First of all, it's sometimes wrong for our purposes. Next, on Wikipedia, we almost always provide a caption for each image. Since the alt text is always read immediately before the caption, we need to stress two things: (1) Sighted users see only the caption; and (2) Screen readers voice both the text and the caption. That may seem obvious, but it's the key to writing alt text.
George Washington on horseback in winter Valley Forge
Painting is by John Dunsmore ca. 1907 and shows both George Washington an the Marquis de Layfayette on horseback. Note small cabins in the background. Image from Library of Congress
Painting of George Washington and companions on horseback in winter.
Washington and Lafayette at Valley Forge
Let me take an example that Penn State uses: the painting of Washington and Lafayette at Valley Forge by John Ward Dunsmore. They suggest alt text of "George Washington on horseback in winter Valley Forge" and a caption of "Painting is by John Dunsmore ca. 1907 and shows both George Washington and the Marquis de Layfayette on horseback. Note small cabins in the background. Image from Library of Congress. Now imagine you hear the alt text and then the caption. You get 4 pieces of information from the alt text, and roughly 8 pieces of information from the caption. But you get "George Washington", "on horseback", and "Valley Forge" twice. In other words, the alt text just adds the "winter" information, and annoys the screen reader user by duplicating three pieces of information. Surely that can't be right?
So let's improve on that if we can. On Wikipedia, we use the image description page to contain detail not relevant to the article, so while "Painting is by John Dunsmore ca. 1907" and "Image from Library of Congress" might be relevant if the image were used in the John Ward Dunsmore article, they would be extraneous to the article on George Washington or Valley Forge.
We don't want the caption to dwell on irrelevant detail, so let's try to work out what we want to say about the image if it were used in an article about Valley Forge (hint: it is used there). How about "Washington and Lafayette were on horseback in the winter at Valley Forge"? Ask yourself how much of that can be deduced from seeing the image (so needs to be made available to a screen reader, but doesn't need to be in the caption because a sighted reader can already see that)?
I suggest "Washington", "horseback", "winter" are likely to be apparent from the image (maybe not Washington) on seeing the image. So we could write alt text to convey that: alt=Painting of George Washington and companions on horseback in winter.
That would leave "Lafayette" and "Valley Forge" to go in the caption. I'd duplicate "Washington" to make the caption sensible, so we could have a caption: Washington and Lafayette at Valley Forge.
If we read those two together we get "Painting of George Washington and companion on horseback in winter. Washington and Lafayette at Valley Forge" for the screen reader user. Isn't that an improvement?
When it comes to teaching editors a new skill, we need a combination of well-written guidance and plenty of good examples as a starting point. The rest comes from practice and feedback. --RexxS (talk) 20:22, 9 April 2020 (UTC)
Wanted to say thank you for the excellent writeup and I plan to reply to it in depth when I make time. Kees08 (Talk) 07:02, 15 April 2020 (UTC)

Logo alt text[edit]

I started a discussion on rephrasing the guideline at Wikipedia:Logos#Accessibility. The discussion is at Wikipedia_talk:Logos#Rephrasing_accessibility. It is going well so far, but if anyone has additional input or concerns feel free to add to the discussion. Kees08 (Talk) 07:07, 15 April 2020 (UTC)

WP:CONTRAST[edit]

Having a discussion about the color scheme for the NFL's Miami Dolphins with other users, and it came to my attention that the "Colour Contrast Check" from snook.ca uses "brightness difference" as a determining factor for whether a color scheme meets the WCAG 2.0 contrast ratio formula. I do not see anything listed at Wikipedia:Manual of Style/Accessibility for brightness, and was under the impression that the contrast ratio is the only thing that matters to pass WP:CONTRAST.

For this specific dispute, there are two color schemes for the Dolphins that both might not pass WP:CONTRAST:

  • White font on an aqua background ([2]) is marked as "sort of" compliant for meeting the "brightness difference" threshold, but it is not WCAG 2 AA Compliant for normal text
  • Black font on an aqua background ([3]) is marked as "not compliant" because of its brightness difference, but it passes WCAG 2 AA for normal and large font

Can someone comment on "brightness difference" being used to pass WCAG 2.0, and if either of the two color schemes options are viable for accessibility purposes? Eagles 24/7 (C) 15:08, 13 May 2020 (UTC)

@Eagles247: Snook's tool gives results against both WCAG 1 and WCAG 2 criteria. The former uses 'brightness difference' and 'color difference' according to an algorithm; the latter uses 'contrast difference' using a different algorithm. The WCAG 1 criteria were aimed at ensuring that text was also discernible on a monochrome monitor, or by someone who had no effective colour vision. I usually recommend this site (linked from http://www.w3.org/WAI/standards-guidelines/wcag/docs/ Understanding WCAG 2) for anyone wanting to understand what the criteria mean.
If you are only implementing the very least standards required to "tick the boxes" for WCAG 2, then both of the schemes pass WCAG 2 AA level. But I can barely read the first one on Snook's site and the second one is difficult to read in greyscale. I would find difficulty in reading text on Wikipedia using them, but that's just anecdote.
If you want to be as accessible as is reasonably possible, you make sure that colour combinations pass WCAG 2 AAA standard, and also pass the older WCAG 1 standards. Peoples' eyesight didn't improve just because a new standard came out. --RexxS (talk) 18:20, 13 May 2020 (UTC)
That 456 Berea Street page is easier to read than Wikipedia. --Redrose64 🌹 (talk) 19:02, 13 May 2020 (UTC)
The project was told a few times over the years that the navigation templates under the projects scope do not meet contrast nor meet basic navbox colors recommendations (odd the project hides it's main article links).--Moxy 🍁 20:28, 13 May 2020 (UTC)
@Moxy: Do you know who posted accessibility messages at WT:NFL? I ran a search of your username and only found this notice about a portal being deleted. I would be surprised if posts were intentionally being suppressed at WT:NFL. In any case, I am willing to go through and make sure color schemes on NFL-related templates meet accessibility guidelines. Eagles 24/7 (C) 20:40, 13 May 2020 (UTC)
If I am not mistaken it was a post about MOS:LINKCOLOR that also mentions contrast problems....main links in navigation templates are hidden by color.--Moxy 🍁 20:47, 13 May 2020 (UTC)
@Moxy: I've seen some navboxes using colors improperly like here, and I will remove the excess color on similar templates. Eagles 24/7 (C) 21:03, 13 May 2020 (UTC)
This matter has been addressed in at least two different ways; both use default colours for most of the navbox and confine the custom colours to areas where text is not displayed, thus avoiding contrast issues. One uses custom colours for the top and bottom borders - see for example Libby Lane#External links; the other uses custom colours for the side borders, see for example Paddington tube station (Bakerloo, Circle and District lines)#External links. --Redrose64 🌹 (talk) 21:32, 13 May 2020 (UTC)
Same type of solution we did for Template:Infobox historic site ☺--Moxy 🍁 22:03, 13 May 2020 (UTC)

Dyslexia Extension[edit]

Hi, I recently started work on my first extension. I've been putting it together to make Wikipedia more dyslexia-friendly. What I knew going in was:

  • Yellow backgrounds are always good
  • Dyslexic fonts would be useful
  • Larger, more readable text would be optimal.

Now, I am not dyslexic, but the only dyslexic person I talked to said that they preferred blue backgrounds, so I made a toggle between those two colours. I couldn't find a js Dyslexic font library, so I used Comic Sans. If you are dyslexic, or know some things about it, some help or suggestions would be greatly appreciated. View it so far at this link. Thanks! (PS: please @me if you respond) WikiMacaroons (talk) 10:57, 25 May 2020 (UTC)

sortable table headers[edit]

Are these table headers accessible? (example 1 below) and are there any better ways to do this? The problem is that for sortable tables the sort icon is beside the heading (example 2), which makes the table a lot wider if there are several narrow columns, which leaves a lot less space for wider columns, particularly with full sized text (example 3). One of the wiki help guide pages suggested putting sort icons below by putting a blank header cell underneath (example 4). But the discussion for that help page (which i unfortunately can't find now) said that blank header cells are very confusing for screen reader users? Irtapil (talk) 13:04, 27 May 2020 (UTC)

example 1. first example
Letter or Digraph Connected
Forms
Languages and pronunciation Unicode Shape i'jam & other additions Similar Arabic Letter(s)
sort sort sort sort 1st 2nd above below sort
ڤ ڤـ ـڤـ ـڤ Ve, used in by some Arabic speakers to represent the phoneme /v/ in loanwords, and in the Kurdish language when written in Arabic script to represent the sound /v/. Also used as pa /p/ in the Jawi script and Pegon script. U+06A4 ڡ 3 dots ف
پ پـ ـپـ ـپ Pe, used to represent the phoneme /p/ in Persian, Pashto, Punjabi, Khowar, Sindhi, Urdu, Kurdish; it is not used in most Arabic varieties (except Mesopotamian and Gulf) and it is normalized as /b/; e.g., pepsi > bibsi. U+067E ٮ 3 dots ب
example 2. sort icon in the same cell as the heading
Letter or Digraph Connected
Forms
Languages and pronunciation Unicode Shape i'jam & other additions Similar Arabic Letter(s)
1st 2nd above below
ڤ ڤـ ـڤـ ـڤ Ve, used in by some Arabic speakers to represent the phoneme /v/ in loanwords, and in the Kurdish language when written in Arabic script to represent the sound /v/. Also used as pa /p/ in the Jawi script and Pegon script. U+06A4 ڡ 3 dots ف
پ پـ ـپـ ـپ Pe, used to represent the phoneme /p/ in Persian, Pashto, Punjabi, Khowar, Sindhi, Urdu, Kurdish; it is not used in most Arabic varieties (except Mesopotamian and Gulf) and it is normalized as /b/; e.g., pepsi > bibsi. U+067E ٮ 3 dots ب
example 3. sort icon in the same cell as the heading with full sized text
Letter or Digraph Connected
Forms
Languages and pronunciation Unicode Shape i'jam & other additions Similar Arabic Letter(s)
1st 2nd above below
ڤ ڤـ ـڤـ ـڤ Ve, used in by some Arabic speakers to represent the phoneme /v/ in loanwords, and in the Kurdish language when written in Arabic script to represent the sound /v/. Also used as pa /p/ in the Jawi script and Pegon script. U+06A4 ڡ 3 dots ف
پ پـ ـپـ ـپ Pe, used to represent the phoneme /p/ in Persian, Pashto, Punjabi, Khowar, Sindhi, Urdu, Kurdish; it is not used in most Arabic varieties (except Mesopotamian and Gulf) and it is normalized as /b/; e.g., pepsi > bibsi. U+067E ٮ 3 dots ب
example 4. sort icons in blank cells
Letter or Digraph Connected
Forms
Languages and pronunciation Unicode Shape i'jam & other additions Similar Arabic Letter(s)
1st 2nd above below
ڤ ڤـ ـڤـ ـڤ Ve, used in by some Arabic speakers to represent the phoneme /v/ in loanwords, and in the Kurdish language when written in Arabic script to represent the sound /v/. Also used as pa /p/ in the Jawi script and Pegon script. U+06A4 ڡ 3 dots ف
پ پـ ـپـ ـپ Pe, used to represent the phoneme /p/ in Persian, Pashto, Punjabi, Khowar, Sindhi, Urdu, Kurdish; it is not used in most Arabic varieties (except Mesopotamian and Gulf) and it is normalized as /b/; e.g., pepsi > bibsi. U+067E ٮ 3 dots ب

One a related note, are blank cells in the body of a table a problem? i presume they'd just be interpreted as "none" by screen-reader users, the same as they would be by a sighted users? but i guess while i'm at it i should check that assumption? On a long table blank cells are visually are a clearer way to show it than some cells having something written and some saying "none" or something else, if the cells all have writing it's harder to see at a glance. But if blank cells are a problem for screen reader users then i'll do it differently. Irtapil (talk) 13:04, 27 May 2020 (UTC)

Irtapil, i understand you are looking for hard answers, but those do not really exist. Almost every combination of accessibility technology with a type of browser will handle this differently. Accessibility for tables is simple. KISS. And anything wider than 720px is hardly useful on mobile. —TheDJ (talkcontribs) 13:19, 27 May 2020 (UTC)

Discussion at WT:JAPAN#On the italicization of foreign-language song titles[edit]

 You are invited to join the discussion at WT:JAPAN#On the italicization of foreign-language song titles. Psiĥedelisto (talkcontribs) 22:44, 27 May 2020 (UTC)

WMF blog post of interest[edit]

Hello all! The WMF has a new blog post that may be of interest. Cheers, {{u|Sdkb}}talk 23:59, 27 May 2020 (UTC)

Making it easier to add captions to tables[edit]

Who do we need to talk to about changes to the editing functionality? When a user uses the button on source editor window to insert a table, there is no caption by default, and it's not even one of the checkbox options. So the user needs to know to type in a "|+" line manually. Most user probably don't know that, so most new tables get no caption. Can the caption line be added to the default version of the table, and checked by default or non-optional? Who do we need to talk to to implement this?

There is currently no caption when inserting a table in source editor

what currently gets inserted:

Header text Header text
Example Example
Example Example

suggestion:

Title for table
Header text Header text
Example Example
Example Example

Irtapil (talk) 13:31, 9 June 2020 (UTC)

That dialog is part of the Wikieditor extension. Maybe WP:VPT to discuss it? DMacks (talk) 13:56, 9 June 2020 (UTC)
Recently filed phab:T252350. --Izno (talk) 14:26, 9 June 2020 (UTC)
This has been done now. the wub "?!" 21:41, 26 June 2020 (UTC)
@The wub: That's working fine now. Thank you for doing all the work in making that happen. Cheers --RexxS (talk) 22:20, 26 June 2020 (UTC)

Missing characters from the Cyrillic letter set[edit]

There are two characters missing from the Cyrillic letter set, the capital and lower case versions of the alternative form of the Cyrillic letter el. Discussion at WP:VPT#Cyrillic letter el. These two really need adding to the character set as it impacts on the Bulgarian, Macedonia, Serbian and Russian languages. The letters are currently not recognised by screen readers when {{lang}} is used. Mjroots (talk) 08:35, 12 June 2020 (UTC)

Articles contradicting MOS:COLOR, MOS:TABLECAPTION, and other basic accessibility guidelines.[edit]

@Lil-unique1 and Graham87: as you two have discussed this with me before. Please see Talk:List_of_American_supercentenarians#Please_see_the_accessibility_guidelines and the related page itself List_of_American_supercentenarians, where another user keeps on removing semantic features in the table. ―Justin (koavf)TCM 02:04, 1 July 2020 (UTC)

Firefox Accessibility Inspector is out of beta[edit]

http://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector#Accessing_the_Accessibility_InspectorJustin (koavf)TCM 01:40, 2 July 2020 (UTC)

Talk to Wiki[edit]

Hi, I've made a beta version of an extension that enables voice activated functionality on WP. Please read installation and usage at User:WikiMacaroons/Talk to Wiki. I'd really appreciate feedback, suggestions, etc. on the talk page. Thanks again, WikiMacaroons (talk) 12:36, 8 July 2020 (UTC)

2019 term opinions of the Supreme Court of the United States and related pages[edit]

2019 term opinions of the Supreme Court of the United States, and other pages using the templates on it (e.g. Template:SCOTUS-termlist-entry) are an accessibility and usability nightmare. It's all a giant table with red-green color coded cells without text in those cells. Even though I'm not colorblind or anything, I took one look at it and recoiled in terror.

Wikipedia:WikiProject U.S. Supreme Court cases had discussed it back in 2015-2016 on Template talk:SCOTUS-termlist-entry, and at Wikipedia_talk:WikiProject_U.S._Supreme_Court_cases/Archive_12#Color-coded_term_list_tables, but it seems to have trailed off into nothing. I'm not an expert on the US Supreme Court or accessibility, so I'm reluctant to try to fix it myself. Maybe one of you can? -Apocheir (talk) 23:40, 9 July 2020 (UTC)

Accessibility Maintenance Categories and more at WP:LAKES[edit]

Has there been a coordinated effort to create tracking categories for maintenance and cleanup of the Infobox parameters and adding to CleanupWorklistBot to specifically check for accessibility practices and opportunities? The categories would be good to get more at the statistics and progress on accessibility practices compared to the MOS across Wikipedia. For instance I've added to WP:LAKES an accessibility review section and we added to the Infobox Body of Water tracking categories (currently just presence/absence). I think it would be useful to also look across the Accessibility practice rules of "good" and "bad" to parse each article for these. Picking out the simplest or most impactful to prioritize the building of categories. What does the project think of coordinating tracking of accessibility practice across Wikipedia? Wolfgang8741 says: If not you, then who? (talk) 09:22, 16 July 2020 (UTC)

Ok, just found Category:Accessibility issue tracking categories, but I don't know if projects are aware of these and will see if they can be added to the bot. Would still love any input on specific things WP:LAKES should highlight. Wolfgang8741 says: If not you, then who? (talk) 09:27, 16 July 2020 (UTC)

Reverting the removal of accessibility features and vandalism[edit]

I've become more concerned lately with accessibility in the encyclopedia and I've particularly seen it come up in terms of MOS:TABLECAPTION, as this recently passed RfC. I am interested in getting thoughts and buy-in from others on the following proposals for cases where other editors remove accessibility features (such as table captions):

  1. A kind of rapid-response team of editors who are willing to be pinged to come to an article and watch, revert, or post to a user's talk page as necessary when a dispute comes up over accessibility in an article. E.g. User A adds proper table semantics, User B removes them for reasons like, "We don't do this" or "I don't like the way this looks" or "What is this?", and User A has a group of other editors willing to intervene. This keeps there from being any one user engaging in a kind of war of attrition or trying to make a case by himself on talk. For users who are willing to listen, having multiple voices will be helpful, for those who aren't, it's easier to make a case to an admin (e.g. at WP:AIV) that User B is acting in an unacceptable way.
  2. Creation of welcome/warning templates or the modification of existing ones to point out the necessity of having basic accessibility on pages (alt text, table semantics, etc.) We have a suite of welcome and warning templates that say things like, "Thanks for your test edit but..." or "Welcome to Wikipedia..." or "Your edits were reverted because..." and removing accessibility features should be included in this set of user talk page templates.
  3. Adding language via an RfC to WP:VANDALISM that makes the removal of accessibility features constitute vandalism. This means it would be explicitly disapproved of and users would be sanctioned to rollback these edits, escalate warnings, and admins would be empowered to block.

Thoughts? ―Justin (koavf)TCM 21:56, 23 July 2020 (UTC)


  • @RexxS, Graham87, and Lil-unique1: I've worked with all of you on accessibility. Can you please give your feedback on these or ping anyone else who can give perspective? @Sdkb: if you have anyone else that comes to mind, please invite. Thanks. ―Justin (koavf)TCM 23:29, 29 July 2020 (UTC)

Koavf, for (2), a templated message explaining to users who mess up something related to accessibility sounds good. I think it would be better structured as something that could be given to more experienced editors, kind of like Template:Ping fix; for brand new editors, they're having so much information thrown at them that they're not going to absorb things like alt text.
For (3), I don't think that would be possible. The Wikipedia definition of vandalism is not at all about how positive/detrimental an edit is, but rather 100% about the intent of the editor. If someone makes a good faith edit that harms accessibility, no matter how bad it is, it can't be vandalism unless it was purposefully trying to harm. {{u|Sdkb}}talk 00:10, 24 July 2020 (UTC)
I don't have much to add to the comment above, except for #1, I don't think the issues are that high-priority that a "rapid response" team is warranted. Even some good-faith editors don't respond well to an influx of strangers criticising their position, believing that they're being ganged up on. Graham87 02:41, 30 July 2020 (UTC)
@Justin: Apart from Graham's concern about an editor feeling "ganged up on", I think #1 has merit. As one of the likely responders, I would try my best to seek to educate editors who cause problems first, and escalate only the most intransigent cases. I think that #2 is a good idea as long as we can avoid having a plethora of templates with the same or similar messages. Perhaps we could find some space here to discuss candidates for new templates if they are sandboxed first. I'm afraid that I don't think #3 can fly. We can't change the fundamental wiki-definition of vandalism. As long as an editor believes that their edit is improving the encyclopedia, they are not committing vandalism, no matter how wrong they are in their belief.
Improving accessibility on-wiki is a long-term job, involving patient explaining, cajoling, suggesting, demonstrating best practice, and waiting for "the penny to drop" across a huge number of editors, many of whom are experienced, just not in the issues surrounding accessibility. This is a mission, not a battle, and the less we annoy other editors (even when they are in the wrong), the more chance we'll make progress. All the best. --RexxS (talk) 19:18, 30 July 2020 (UTC)
I think the main effect (perhaps goal as well?) of #3 would be making restoring accessibility features exempt from 3RR. I haven't thought too much about the pros and cons of that happening, but if that's the goal, I reckon adding it directly to WP:3RRNO is a better path than adding it to our definition of vandalism. --Mdaniels5757 (talk) 21:28, 30 July 2020 (UTC)
@Mdaniels5757: I understand the desirability of making good edits into exemptions from 3RR, but the problem that I anticipate is the use of any such exemption as a means of pushing the accessible version through by edit-warring. I believe that we have policy on our side and should be able to make the case on the talk page if reversions of accessibility changes take place. I know it's more work, but it's really essential in the long run to get the message across, and we'll only do that by debate, not by reverting. Cheers --RexxS (talk) 22:14, 30 July 2020 (UTC)
My issue with #1 is demonstrated over there. Whether you think you're helping the Wikipedia or not, 'fast response team' sounds like 'let just get the squad and hit up the battleground'. This page, or WT:ACCESS, are sufficient locations to notify users of potential accessibility issues. --Izno (talk) 02:06, 31 July 2020 (UTC)

WikiMacaroons' wiki-ad:[edit]

-iaspostb□x+ 11:36, 31 July 2020 (UTC)

Nice. But presumably 4.7% of our editors can't read the invitation to join WikiProject Accessibility either? --RexxS (talk) 17:36, 31 July 2020 (UTC)
The closer they (and we) look at the text, the easier it is to read it. -iaspostb□x+ 04:53, 2 August 2020 (UTC)
It's also completely inaccessible for screen reader users like me ... Graham87 15:31, 2 August 2020 (UTC)
Indeed; although it's got alt text, that alt text does not describe the image - it should be text associated with an image that serves the same purpose and conveys the same essential information as the image. --Redrose64 🌹 (talk) 08:35, 3 August 2020 (UTC)