Wikipedia talk:WikiProject Accessibility/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Reporting an image with just two colors (green and "burnt orange") that look identical to me

Okay, so I have deuteranomaly, the most common form of colorblindness in humans, especially humans with only one X chromosome, because it is X-linked. Here is the article:

United States presidential election, 1800

Here is the file with only two colors and they look almost identical to me:

ElectoralCollege1800.svg (WikiMedia.org)

I can see the colors have been changed in the past. Although deuteranomaly is often called a type of "red-green colorblindness", this map would actually be fine for me if the colors were red and green. But they are "burnt orange" and green. A nice firetruck-red color combined with the existing green on that map would be immediately visible to me. I understand why it doesn't use firetruck red, that color corresponds to a different political party in the same country, namely the Republican Party as it exists today and has existed for a long time, but not in 1800. The map also cannot use blue for this reason.

Because this map deals with the intersection of previously-established color-political party relationships (so red and blue are both taken) and accessibility for people with color vision deficits, I am actually not sure what specific colors to suggest. The existing green along with either red (like the US Republican Party) or blue (like the US Democratic Party) would be fine, especially if there was a large difference in luminance, and if both were fully saturated. The "burnt orange" is of very similar luminance subjectively for me, and it is objectively not fully saturated. It looks like there should actually be a luminance difference, but that will depend on monitors, and my subjective perception of brightness is different than humans with normal color vision, so the small difference that allegedly exists according to my "eyedropper tool" is small by any measure, and imperceptible to me. I don't even remember which is supposedly brighter, I think the "burnt orange" was brighter, but I can't see it with my eyes.

To be fair, upon looking very closely I can see the different colors. But I was astonished for quite a few seconds that John Adams "had lost Massachusetts in 1800". He did not, that state is his color. (It's his home state, if I recall correctly. I was astonished that he didn't even win his home state. The map looked like an almost solid sweep for Thomas Jefferson except for the states where they give electors to more than one candidate, because the circles surrounded by a different color with no white gap were visible to me immediately. The map looked like one color swept the map, but in fact the election was close.)

Edit: This seems to be heavily dependent on monitor hardware, but not software. On my smartphone, the colors are very obviously different to my colorblind eyes. On my laptop, they are so nearly identical that I thought the election was a landslide for a few seconds, until I looked at the text and then looked again very carefully at the map. The SVG and the PNG look the same to me, and they look the same in both Firefox and Okular (KDE application for PDFs and image files). The screen on my smartphone is very different technology versus my laptop, but usually things look the same in my opinion, apart from my phone being annoyingly glossy and reflective.

Thank you. Fluoborate (talk) 10:15, 6 November 2018 (UTC)

The original uploader is Walk_Like_an_Egyptian and it looks like he is still contributing. Maybe he can comment or make a tweak to the files he's uploaded. --Izno (talk) 20:25, 6 November 2018 (UTC)

There's also the possibility of using horizontal stripes for one party and vertical stripes for the other one. Or stripes for one and dots for the other one. I've seen such things in black-and-white books. But but I've read that some patterns may cause epileptic seizures. So I'm not sure if they would work here.

Something like "it's mostly green, but the north-east is mostly salmon" could help a bit. But US geography has changed since the time shown on this map, so it's not really the north-east of the modern day United States. So if someone knows how to write a good text summary of the map, they might want to add one to the image description page. A short description of the image could also be added as an alt text in the article. – Pretended leer {talk} 21:20, 6 November 2018 (UTC)

Talk:Sabrina_Carpenter_discography#WP:ACCESSIBILITY violations

There is a discussion regarding the use of rowspan in discography articles at Talk:Sabrina_Carpenter_discography#WP:ACCESSIBILITY violations. Editors are welcome to participate and voice opinions. Flooded with them hundreds 17:39, 14 November 2018 (UTC)

Reference quotations given only as tooltip

At California housing shortage I noticed the interesting usage of referenced quotations being displayed in a tooltip (mouseover the dotted-underline in various refs). It was discussed at Template_talk:R#New_quote_feature in late 2017. I believe this feature has a few accessibility issues, but I don't have time to dig deeper so am noting here with the hopes someone else can. Quiddity (talk) 21:37, 21 November 2018 (UTC)

@Quiddity: Yeah, that doesn't work well for screen readers. But I have no idea what should be done here ... having the quotes spoken outside the ref would be weird for screen reader users too, and having them inside would defeat the whole purpose of the template. Graham87 05:57, 22 November 2018 (UTC)

Accessibility settings panel - Wishlist

I took the ideas we've been collating at phab and elsewhere, and put them in m:Community_Wishlist_Survey_2019/Reading/Accessibility_settings_for_everyone. Please vote, comment with other ideas, etc. :) Quiddity (talk) 06:13, 22 November 2018 (UTC)

Seeking feedback on WMF Grant Proposal "Accessibility of equation rendering"

Volker Sorge/zorkow and I (pkra) have been working on a Wikimedia Foundation grant proposal for 2019 at [1] entitled "Accessibility of equation rendering: a comparative evaluation". From our summary:

"We propose a study to analyze the accessibility of equation rendering techniques on the web. This evaluation will focus in particular on the techniques currently used on Wikimedia sites as well as alternatives that are feasible to adopt for Wikimedia."

It would be very helpful to get feedback from the community. If you could help spread this further (or have recommendations for us to do that), that would be very useful as well. Of course we would also be thrilled if you might consider endorsing the proposal.

Thanks in advance--Pkra (talk) 12:56, 28 November 2018 (UTC)

having problems with editing wikipedia as a blind individual

greetings. i am having problems with editing an existing artical on wikipedia do to the editor being very inaccessible. any help would be very much appreciated — Preceding unsigned comment added by 82.163.229.192 (talk) 10:51, 30 November 2018 (UTC)

Hey, I'm a totally blind screen reader user who is also an admin here. The editor on this site is quite accessible ... it's just text ... but it does take some getting used to, and for larger editing tasks I find it can be easier to edit from a text editor. please email me at grahamwpgmail.com and let me know which screen reader you're using and what you're trying to do. Graham87 14:48, 30 November 2018 (UTC)

Contrast between visited & unvisited links

Please see Contrast between visited & unvisited links. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:07, 30 November 2018 (UTC)

Captcha vs. screen reader

I am hoping someone can either point me to a solution or address the question themselves. I ran across an editor using a screen reader who indicates our use of Captcha prevents them from creating an account, so they are editing anonymously. They also indicate this prevents them from adding inline cites, so they are putting them in the edit summaries. Obviously, this is not acceptable in terms of user experience or citing sources.

While I assume we have added audio Captcha by now and/or have another solution, I haven't been able to find anything explaining either one. I have very limited experience with Captcha and no experience with screen readers. Who is a relative expert here? If you are willing to take over, the user in question, Nahom, is currently at User talk:23.151.192.180. - SummerPhD^v2.0 22:55, 23 January 2019 (UTC)

One for you, Graham87! --Redrose64 🌹 (talk) 23:20, 23 January 2019 (UTC)

I've responded there. Graham87 04:47, 24 January 2019 (UTC)

Thanks! - SummerPhD^v2.0 05:38, 24 January 2019 (UTC)

Attention requested for a table's accessibility - again

Accessibility disagreements have broken out at Talk:2019 Formula One World Championship#Request for comment on table sorting. It centres around a table listing motor racing teams and their drivers, each team having two cars and thus two drivers. At least two different people have offered opinions as to what form the table should take in order to be accessible. --Redrose64 🌹 (talk) 19:11, 26 February 2019 (UTC)

Technical advice needed; Thanks

FYI

 – Pointer to relevant discussion elsewhere.

Posted at VPT by John Cline (talk · contribs): Wikipedia:Village pump (technical)#Technical advice needed; Thanks. This concerns the width of an infobox when the browser is zoomed in, and I see it as an accessibility concern. --Redrose64 🌹 (talk) 11:30, 12 April 2019 (UTC)

Accessibility issue?

I asked about reasons for not linking in section headers at Wikipedia_talk:Manual_of_Style/Linking#Links_in_section_headers. one of the replies suggested there may be an accessibility problem, so checking here. Please ping with reply, Cheers, · · · Peter Southwood ^(talk): 05:30, 25 April 2019 (UTC)

@Peter: no current issue that I'm aware of. I've made a demo at Wikipedia talk:Manual of Style/Linking #There is a link to the Main Page in this section header. Cheers --RexxS (talk) 14:19, 25 April 2019 (UTC)

Thanks RexxS, · · · Peter Southwood ^(talk): 17:19, 25 April 2019 (UTC)

This makes me angry

Have you seen these comments? --Redrose64 🌹 (talk) 21:44, 8 May 2019 (UTC)

CSS Color Adjust Module Level 1 published

Hopefully of interest to this WikiProject is CSS Color Adjust Module Level 1 which was published yesterday as a "W3C First Public Working Draft"; its abstract states This module introduces a model and controls over automatic color adjustment by the user agent to handle user preferences, such as "Dark Mode", contrast adjustment, or specific desired color schemes.. Of course it will be some years before its provisions are embraced by browser vendors. --Redrose64 🌹 (talk) 18:42, 22 May 2019 (UTC)

Minimum font size

I've been poking around a number of other W3C working drafts, and have found a proposal for a font-min-size property which will allow an author or user to require that an element’s font size be clamped within the specified range. If the specified value font-size is outside the bounds created by the used font-min-size and font-max-size, the computed value of font-size is clamped to the values specified in these two properties. --Redrose64 🌹 (talk) 18:40, 27 May 2019 (UTC)

Colour usage in recent European Parliament election articles

Currently there are discussions related to colour usage on two articles related to the recent European Parliament elections, if anyone is interested in contributing: Talk:2019 European Parliament election#Overcoloured and Talk:2019 European Parliament election in the United Kingdom#Misuse of colour. -- DeFacto (talk). 18:33, 28 May 2019 (UTC)

list gaps in lists of lists, is it meant to work like this?

Apparently if you put a bulleted list inside one of the definitions in a definition list, at the end of a definition, it makes the definition list end right after the bulleted one. Now, if you put a blank line with just the colon after the bulleted list, it doesn't end the list, but it does put in a blank element. So it seems this is wrong:

; Cats
: Animals that make several different sounds:
:* meow
:* purr
; Mosquitoes
: These animals rarely speak, or at least that's what humans think. Humans do here them buzz sometimes. 

And this doesn't seem perfect either, but it was the least wrong I could come up with:

; Cats
: Animals that make several different sounds:
:* meow
:* purr
:
; Mosquitoes
: These animals rarely speak, or at least that's what humans think. Humans do here them buzz sometimes.

So I'm guessing the latter is preferred but, I'm really not sure. – Pretended leer {talk} 09:59, 6 August 2019 (UTC)

I think it was Anomie and I who recently discovered this. This issue probably should be a rarity because you should not be putting complex list blocks into this kind of list in the general case (at least in articles; talk pages are a lost cause anyway). --Izno (talk) 14:08, 6 August 2019 (UTC)

thanks! The article where I saw this seems to be using definition lists for something that... it's not really definitions, but it's mostly single sentences. It's this one: Solved game. Is it the kind of situation where bold paragraphs would be appropriate? – Pretended leer {talk} 14:35, 6 August 2019 (UTC)

That particular article's bullet list could probably be made into a single paragraph. I haven't given a lot of thought to whether that should be an association list at all, but on first observation that looks reasonable. --Izno (talk) 17:12, 6 August 2019 (UTC)

Win-Loss colors on season tables

I have a quick question since it was brought up at Talk:Utah Warriors#Colored tables. The colors   and   are used on hundreds (thousands?) of articles designating won and lost games as backgrounds on tables in season pages. In the linked discussion, the editor has claimed these fail accessibility, but when I use the tools in MOS:CONTRAST, it says they are fine.(red and green) As I am no expert here, is it truly an accessibility issue or of a personal preference/over-decoration issue? (If it is the former, a longer discussion probably needs to take place. If it is the latter, then it would just a consensus style discussion for that particular group.) Yosemiter (talk) 05:04, 13 February 2019 (UTC)

Those colours fail Snook's Colour Contrast Check when checking against linked text (black text is okay), but not by much. It's not enough to start a war over, but slightly less saturated background colours (e.g.   and  ) would render links more legible, especially visited links against the red background. I've left some comments and recommendations at Talk:Utah Warriors #Colored tables, but that will be pertinent to any use of those colours as backgrounds. --RexxS (talk) 15:53, 13 February 2019 (UTC)

@RexxS: Appreciate the comments. As I stated there, I do not have any particular preferences, I was was just carrying over what has been typically used in the past (which is not a justifiable reason to continue using per se, as described in WP:OTHER). It may be worth bringing up the contrast issues with linked text as it is widely used by Wikipedia:WikiProject Sports. Yosemiter (talk) 16:17, 13 February 2019 (UTC)

@RexxS: You wouldn't happen to have the color code for visited links handy? I believe unvisited is #002BB8? Yosemiter (talk) 23:11, 21 March 2019 (UTC)

@Yosemiter: The default colour for visited links for Vector skin is #0B0080 (although it's #5A3696 in Monobook skin). You're right about unvisited. --RexxS (talk) 23:25, 21 March 2019 (UTC)

@RexxS: @Yosemiter: Late coming to this, but default colours can be found at WP:LINKCOLOR, which indicates that the default colour for unvisited links is actually lighter (#0645AD). —Domeditrix (talk) 22:00, 11 August 2019 (UTC)

@Domeditrix: Sorry I wasn't very clear about that. #002BB8 is the base colour for Monobook links, i.e. 'unvisited' (defined by a {color: #002bb8;}) as you can check with the inspector. You're right about Vector, but it's annoying for old-timers that WP:LINKCOLOR only considers Vector skin. --RexxS (talk) 22:39, 11 August 2019 (UTC)

Improving accessibility in club seasons articles: A proposed template update

There is currently an ongoing discussion on the WikiProject Football talk page regarding potential changes to the club seasons template. Any input from those with some knowledge on the topic would be extremely welcome – I think we're quite well-meaning but fumbling in the dark a little! Domeditrix (talk) 14:06, 12 August 2019 (UTC)

Use of small text

When is use of small text helpful and when is it unhelpful? Specifically, is the use of small text in Template:Track listing an example where it is helpful?--3family6 (Talk to me | See what I have done) 20:35, 11 September 2019 (UTC)

Semantically, the <small>...</small> element represents side comments such as small print. This is followed by examples, and nothing resembling a music track listing seems to be among them. --Redrose64 🌹 (talk) 21:23, 11 September 2019 (UTC)

@3family6: To add to what Redrose64 says above, pragmatically, Wikipedia has allowed text size to be reduced when space is at a premium, such as in tables and infoboxes. Traditionally, the community has tolerated abuse of semantic markup for practical purposes. I wouldn't recommend misuse of <small>...</small> for convenience in cramming information into a small space; but if you must, then using something like <span style="font-size:90%;"> ... </span> or the {{small}} template, is free of semantic meaning. Please remember, though, that under no circumstances should the resulting font size fall bellow 85% of the normal page font size, for accessibility reasons. --RexxS (talk) 22:36, 11 September 2019 (UTC)

Okay, thank you!--3family6 (Talk to me | See what I have done) 17:10, 12 September 2019 (UTC)

Alt text for formulae

Hello! I believe that I may have started a discussion process about the use of alt text in mathematical formulae. I have learned today that the alt text is automatically generated from the TeX code that was used to generate the formula. Any other alt text given in the <math> environment is currently ignored, contrary to the help pages on the topic. The pertaining existing discussions are at the Talk page of the Help page and most directly at the bug report at [2]. Since the feature of displaying alt text is now back in the state of feature request, it would be excellent to chime in to the discussion. --Lpd-Lbr (talk) 19:00, 17 September 2019 (UTC)

Diagonal split color box

Discussion at Wikipedia_talk:Manual_of_Style/Accessibility#Diagonal_split_color_box AngusWOOF (bark • sniff) 21:50, 17 September 2019 (UTC)

Inconsistent spacing between bars in a television ratings graph

 You are invited to join the discussion at Talk:List of American Horror Story episodes#Graph . Radiphus (talk) 12:45, 20 September 2019 (UTC)

Accessibility and discography articles

Can someone take a look at Lecrae discography and see where it fails the Accessibility policy? This list is typical of discography articles. There were some previous discussions, and I've looked at the guidance for data tables, and I'm still not sure of what is within policy and what is not, and how to fix any violations.

Thanks, --3family6 (Talk to me | See what I have done) 19:39, 6 August 2019 (UTC)

I made a couple of edits to demonstrate increased accessibility [3] and [4], though I am not sure how much is required per se by the guidance. Comments on each:

• The scopes were generally good. I added a 'colgroup' which is approved scope for use when there are subcolumn headers.
• Avoid use of small text (especially the small element in most cases) and arbitrary widths. The former prevents users with bad eyesight from reading and the latter prevents users with varying screens from getting the most out of the table.
• Avoid the list as they were--each of those corresponded to a facet of the title, and you provided them as if they were data--so add a column for each. This isn't strictly necessary but it does enable table simplification and a more 'data' table rather than a 'table used for structure'.
• Provide keys at the beginning of the table rather than later. That makes it obvious to a reader what is going on.
• Likewise remove the note to either before or after the table. This enables a simple table and reduces confusion for an unsighted reader when he gets to that row.

An additional change for the longer table now would be to add the sortable class so a reader with full capabilities can sort on each column if he desires. --Izno (talk) 22:58, 6 August 2019 (UTC)

Thank you! I will try to work on anything which you did not already do. Can you please explain #3, "Avoid the list as they were"?--3family6 (Talk to me | See what I have done) 03:50, 7 August 2019 (UTC)

Uh, trying to say that, because you covered the same content in each of the lists, and each of the lists corresponded to a title, that what you were trying to do was add some more data to the table--for which a table cell for each list item is generally the best. Why else use a table? :) --Izno (talk) 03:30, 8 August 2019 (UTC)

Okay, yes, and I think I ended up doing this anyway. Take a look at where I'm at so far and see if this looks right, if you like.--3family6 (Talk to me | See what I have done) 04:33, 8 August 2019 (UTC)

The tables are a bit inconsistent from the stuff up top down to the stuff toward the bottom with e.g. the styling on the first cell--I think you just forgot to convert those to use exclamation points? The other thing that needs changing is the far right column on the lower tables; you shouldn't use rowspans like that. --Izno (talk) 05:31, 10 August 2019 (UTC)

Izno, yes, I didn't use the exclamation points. Regarding rowspan, do you mean the entries in the "Album" column?--3family6 (Talk to me | See what I have done) 03:26, 16 August 2019 (UTC)

Yes. --Izno (talk) 12:26, 16 August 2019 (UTC)

Thanks.--3family6 (Talk to me | See what I have done) 03:26, 20 August 2019 (UTC)

Izno, anything else outstanding now?--3family6 (Talk to me | See what I have done) 03:39, 22 August 2019 (UTC)

@Izno:, do my edits help solve the accessibility issues? – The Grid (talk) 15:19, 26 November 2019 (UTC) (Pinging 3family6)

Those edits did precisely the opposite. --Izno (talk) 15:35, 26 November 2019 (UTC)

I'm a bit confused. I believe this was asked as part of a peer review, I don't see acknowledgement that the version before my edits solved the accessibility issues. I'm reviewing WP:DTT just because I was brought to this discography page as an example of addressing accessibility issues for discographies in general. – The Grid (talk) 15:44, 26 November 2019 (UTC)

@The Grid: There's no need to be confused. MOS:DTT lays out quite well what is good practice for improving the accessibility of data tables. When you remove ! scope="row" from the row header cells, you make life more difficult for some visitors who use screen readers to navigate around the table. Please don't do it. --RexxS (talk) 16:03, 26 November 2019 (UTC)

Video on the main page

Please make your views known, on Wikipedia talk:In the news#Should animation and video, anywhere on the Main Page, be automatic, optional or prohibited?. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 30 January 2020 (UTC)

Discussion at Template talk:Db-meta#Green on red

 You are invited to join the discussion at Template talk:Db-meta#Green on red. ~ ToBeFree (talk) 22:00, 17 February 2020 (UTC)

Lead section word limit?

The issue of subdividing short articles that don't necessarily exceed the length of a typical article's lead section was recently raised by CaroleHenson at Talk:Washington and Colorado serial rape cases. The related suggestion, that long lead sections can be difficult for users with neurological impairments, makes me wonder if a recommended word limit should be placed on lead sections, in addition to the suggested four-paragraph maximum (paragraphs can be virtually any length). Any thoughts? —Sangdeboeuf (talk) 01:09, 7 March 2020 (UTC)

I have a harder time with "wall of text" articles where there are no sections... so no context about what I am reading and I get lost (reading a paragraph over and over again and still missing points). On long WP articles, I read the table of contents first... and usually the lead last... but the table of contents provides context about what is being discussed.

As a side comment, I recently got really confused doing a GA review on this version of the article because there was career info in Early life and career info in retirement. By the time it was changed to this version, where content was put in relevant subsections for "career". I totally "got" the points through one read through.

So, for me, long leads aren't terribly difficult - because I ignore them until I know more. I hope that makes sense. I would say, though, that it's helpful if there is a logical grouping of what goes in each paragraph of the lead.–CaroleHenson (talk) 02:08, 7 March 2020 (UTC)

I've struck part of my initial comment that was unclear. Carole Henson did not make the connection to lead length, that was me. The fact remains that the article in question is nearly the same length as many articles' lead sections. —Sangdeboeuf (talk) 03:23, 7 March 2020 (UTC)

I was just trying to think how to summarize this issue - which I think are also cases for children and elderly (I have my toes in that category, too)... I think the issue is that I get really lost if information is not grouped logically. I get so confused that I cannot make sense of anything in that paragraph or section. If I have to, like if I am fixing an entire article, it's an arduous process, focusing slowly on one sentence or part of a sentence at a time.–CaroleHenson (talk) 04:17, 7 March 2020 (UTC)

I don't see how one reader's odd choice to ignore leads has any implications for how we write them. The entire point of leads is to concisely summarize all the important parts of an article. It is necessarily going to be true that the longer an article is and the more material there is to summarize, then the longer the lead will be, up to a point. If one finds the larger bulk of the article confusing (whether that's because of the complex nature of the subject or because of a non-ideal sectional organization for a simple subject), then the obvious thing to do is to go read the lead for a précis. If you will not use the tool that exists to solve your problem, it isn't the tool that's at fault. If someone is WP:GAMING the system by writing stupidly long leads in the manner of cramming several paragraphs' worth of material into excessive "mega-paragraphs", or using unnecessarily long-winded sentences to create a lead twice or thrice as long as necessary, that's not really a problem with our lead guidelines. It's a problem with a specific editor and with some specific articles' crappy leads that just need to be rewritten by less tumid editors. I guess I would not have an objection to adding a footnote to MOS:LEAD about not trying to game around the paragraph limits by running paragraphs together to form 3 or 4 blocks of text and then call the paragraphs. But if this is not a widespread problem, WP should not try to make a rule about it (WP:CREEP, WP:MOSBLOAT). But this is not a good page at which to propose changes to MOS:LEAD; try WT:MOSLEAD.  — SMcCandlish ☏ ¢ 😼  12:35, 7 March 2020 (UTC)

Scrolling of a template

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

Feedback requested at Wikipedia_talk:Manual_of_Style#Typographical_symbols_used_for_notes_and_accessibility. Thanks. ―Justin (koavf)❤T☮C☺M☯ 02:03, 21 March 2020 (UTC)

Review of introductory pages

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

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

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

• 
  this is what we are sending our mobile readers to. - Moxy
• 
  Where we are sending our mobile readers to, as seen on Sdkb's phone.

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 [5]. 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

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.

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

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

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

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 ([6]) 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 ([7]) 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 https://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

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

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 (talk • contribs) 13:19, 27 May 2020 (UTC)

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

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

WMF blog post of interest

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

Missing characters from the Cyrillic letter set

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)

Making it easier to add captions to tables

Tracked in Phabricator
Task T252350
Resolved

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)

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

@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)❤T☮C☺M☯ 02:04, 1 July 2020 (UTC)

Firefox Accessibility Inspector is out of beta

https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector#Accessing_the_Accessibility_Inspector ―Justin (koavf)❤T☮C☺M☯ 01:40, 2 July 2020 (UTC)

Talk to Wiki

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)

Accessibility Maintenance Categories and more at WP:LAKES

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

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)❤T☮C☺M☯ 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)❤T☮C☺M☯ 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:

Wikipedia ads	file info – #277

-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)

Thanks for the feedback, folks! :) WikiMacaroons^Cinnamon? 09:19, 12 August 2020 (UTC)

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

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)

Yikes, you're not kidding! I made some updates to Module:SCOTUS-termlist-entry so that the content is more accessible to screen readers. Overhauling the colors in a way that's both accessible and aesthetically pleasing is a project for another day. :) Annettet (talk) 23:42, 15 August 2020 (UTC)

Article discussion that needs accessibility input

Hello, there is a discussion at Talk:Central Business District, Los Angeles (1880s-1890s) regarding an unusual content layout that could use some input regarding accessibility. Thanks for everyone that might have suggestions.   // Timothy :: talk  19:56, 18 August 2020 (UTC)

Request for Six Flags AstroWorld‎

Hello! The Six Flags AstroWorld‎ article has been overhauled recently. I'm curious, are any project member able to make improvements to the article, specifically the table in the List of roller coasters, more accessible? Thank you in advance! ---Another Believer _(Talk) 19:37, 28 August 2020 (UTC)

@Another Believer: I've added scopes and row headers and some simple alt text. I did each step in a separate edit so you can see what I did and revert any that you don't want. Cheers --RexxS (talk) 17:27, 29 August 2020 (UTC)

RexxS, Thank you, --Another Believer _(Talk) 18:27, 29 August 2020 (UTC)

Request for accessibility specifications

• Wikipedia:Village_pump_(WMF)#Request_for_accessibility_specifications

I made a request to the Wikimedia Foundation. Blue Rasberry (talk) 20:38, 8 September 2020 (UTC)

DYK discussion

There's a discussion of how to write good "alt" texts for images (and related topics) at Wikipedia talk:Did you know#Adding an accessibility requirement?. -- RoySmith (talk) 18:03, 11 September 2020 (UTC)

Relevant discussion

See Talk:Naomi_Osaka#Accessibility. ―Justin (koavf)❤T☮C☺M☯ 18:50, 13 September 2020 (UTC)

Link to following Accessibility features on the top of home page

There should be an accessibility shortcuts to the following items on the top of the first and foremost page. They can be helpful for really tough situation.

1. https://wiki.riteme.site/wiki/Help:Multilingual_support , Font and rendering support, IPA, Braille etc.
2. https://www.mediawiki.org/wiki/Universal_Language_Selector
3. https://wiki.riteme.site/wiki/Wikipedia:Spoken_articles
4. Wiki markup language support. (What is a markup language?, what is the Wiki markup language, its List of codes, cheatsheet etc.)

This is a keen request. This should be added on top of all pages, as an accessibility hyperlink. Even this should be added in all other Wikis and as well as Wikipedia home pages. Thank you in advance.

RIT RAJARSHI (talk) 09:51, 14 September 2020 (UTC)

Need help with table color template!

See Template_talk:Shade#color contrast. I am not good enough with Wikitext to figure out a good solution :/ --Artoria2e5 🌉 17:35, 18 September 2020 (UTC)

Default alt text

For certain infoboxes, I could envision a default alt text, such as "Logo of PAGENAME" for the logo in {{Infobox company}}. It would of course be overriden if an alt text is provided, but for the cases where the alt text would otherwise be the file name, would this be an improvement over the status quo? {{u|Sdkb}} ^talk 07:09, 29 September 2020 (UTC)

Meh ... in cases like that, it'd probably duplicate the caption. Graham87 14:33, 29 September 2020 (UTC)

I would also duplicate the caption parameter for the alt; although, if there is no caption, then there is no alt, so maybe in that case, it could default to something like 'Logo of pagename'. Funandtrvl (talk) 17:29, 29 September 2020 (UTC)

Specifically, I'd duplicate 'logo_alt' or 'alt', and if those are empty, then 'Logo of PAGENAME'. Funandtrvl (talk) 17:31, 29 September 2020 (UTC)

The last thing a screen reader user like Graham wants is to hear the same thing twice. That's why alt text should not duplicate the caption. The caption should be providing relevant information that is not obvious from the image and the alt text should be providing (in text form) the relevant information that a sighted reader would glean from seeing the image. --RexxS (talk) 18:25, 29 September 2020 (UTC)

I'm aware of that guideline; however, when the alt parameter is missing entirely, and when it should have something there, is there another way to fill it in, that hasn't been mentioned yet? Funandtrvl (talk) 01:41, 1 October 2020 (UTC)

Yes. In those sort of cases, if there is no relevant information in the image that is not already in the caption, then |alt=See caption. is a neutral choice that screen reader users can quickly recognise and skip over. --RexxS (talk) 14:19, 1 October 2020 (UTC)

Copying alt text for images used in multiple places

Do we have any sort of semi-automated tool that'll allow users to take the alt text for File:Example.jpg used at Foo, and copy it to an instance of the same image at Bar that does not yet have alt text? {{u|Sdkb}} ^talk 05:49, 3 October 2020 (UTC)

RfC about images

* There is an RfC at Talk:List of vegetarians#Request for comment on images that may be of interest to WikiProject Accessibility. Normal Op (talk) 15:13, 16 October 2020 (UTC)

Lists made out of line breaks?

I've seen some pseudo-lists that use line breaks (<br>) instead of bulleted/numbered lists. For example, at Zana Fraillon#Awards. What would be the best way to organize this info to be more accessible? Are bulleted lists like at Gabrielle Wang#Awards the best way, or is there a better way? - Whisperjanes (talk) 15:59, 16 November 2020 (UTC)

This is usually just a sign of copy-pasting from Word and/or COI spam, or of lower quality or just not knowing in general. Convert to the standard list format on sight. --Izno (talk) 16:35, 16 November 2020 (UTC)

@Whisperjanes: there is a template called {{Unbulleted list}} (shortcut {{ubl}}). You should always convert break-separated pseudo-lists into real lists, using either wiki-markup for lists or the list template (the template is most useful in infoboxes and other places where horizontal space is tight). --RexxS (talk) 22:39, 16 November 2020 (UTC)

Thanks! Glad to have a couple of options. - Whisperjanes (talk) 23:33, 16 November 2020 (UTC)

relevant RM

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:WikiProject Disability/Style guide#Requested move 20 November 2020
 — SMcCandlish ☏ ¢ 😼  20:52, 28 November 2020 (UTC)

Group of users interested in changes to CSS

Watchers of this page may be interested in Wikipedia talk:Manual of Style/Accessibility § Group of users interested in changes to CSS. Izno (talk) 22:07, 20 December 2020 (UTC)

Since many editors treat Manual of Style content as mere ignorable guidelines, MOS:ACCESS content should be clearly made non-ignorable policy.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

MOS:ACCESS content, and in particular MOS:PRECOLLAPSE, should be clearly established as policy and not "merely" guidelines.70.52.144.5 (talk) 15:59, 30 January 2021 (UTC)

• Readers should review the discussion at WT:ACCESS#WP:COLLAPSE being ignored and WT:WikiProject Usability#Where to report a Wikipedia page that violates usability guidelines? (clear WP:FORUMSHOP behavior), which this IP is salty about but which we effectively cannot sort beyond telling the IP to WP:SOFIXIT. While I (slightly) agree with the intent of the heading of this supposed RFC, it is clearly in the vein of WP:IDHT rather than in interest of having an actual discussion on the point. --Izno (talk) 17:42, 30 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.