Community Wishlist Survey 2022/Editing/Alert editors when a change would reduce accessibility of the entry or page

Alert editors when a change would reduce accessibility of the entry or page

  • Problem: Editors often make changes that make an entry inaccessible or less accessible to people with disabilities.
  • Proposed solution: Aggregation (or duplication if unavoidable) of existing accessibility checking tools such as https://webaim.org/resources/contrastchecker/ or the https://wave.webaim.org/ suite.
  • Who would benefit: People with disabilities (readers and editors), editors not familiar with accessibility requirements (such as subject matter experts about the entry's topic), editors with a commitment to accessibility (less work, less required knowledge of sometimes-conflicting accessibility requirements).
  • More comments: General discussion of accessibility checker features at https://webaim.org/articles/tools/.
  • Phabricator tickets:
  • Proposer: PauAmma (talk) 23:45, 17 January 2022 (UTC)

Discussion

  • having worked with some of this, just giving ppl tools is not going to help them achieve this. Tools need to be very targeted and tightly integrated if you want users to achieve this goal. Wikis are however very unstructured and this thus makes it by definition very hard to achieve. Do you have specific problems that you would like to see tackled ? —TheDJ (talkcontribs) 11:28, 18 January 2022 (UTC)
  • Maybe this could be used to check the edit before saving and give a warning message when accessibility will be degraded. To start off it would probably be better to allow override or opt-in for registered users, but if it works well it could be upgraded to default. Anyone overriding the warning takes responsibility, but sometimes it may be necessary, specially in beta. · · · Peter (Southwood) (talk): 13:49, 24 January 2022 (UTC)

Voting

  •   Support Lectrician1 (talk) 23:04, 28 January 2022 (UTC)
  •   Support JDspeeder1 (talk) 01:50, 29 January 2022 (UTC)
  •   Support War (talk) 04:20, 29 January 2022 (UTC)
  •   Support Bertotits23 (talk) 05:05, 29 January 2022 (UTC)
  •   Support Mbrickn (talk) 15:42, 29 January 2022 (UTC)
  •   Support Warmglow (talk) 16:54, 29 January 2022 (UTC)
  •   Support WhyIsNameSoHardOmg- - (talk) 19:34, 29 January 2022 (UTC)
  •   Support Anything to improve the ways in which accessibility is (unknowingly) overlooked by editors is worth consideration OwenBlacker (Talk) 22:27, 29 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 07:54, 30 January 2022 (UTC)
  •   Support Thingofme (talk) 15:15, 30 January 2022 (UTC)
  •   Support KevinL (aka L235 · t) 20:53, 30 January 2022 (UTC)
  •   Support Libcub (talk) 22:01, 30 January 2022 (UTC)
  •   Support It would also be nice to highlight changes that aren't mobile-friendly. Trizek from FR 12:12, 31 January 2022 (UTC)
  •   Support LudicrousSengir (talk) 14:08, 31 January 2022 (UTC)
  •   Support Daniel Case (talk) 18:17, 31 January 2022 (UTC)
  •   Support IOIOI (talk) 20:46, 31 January 2022 (UTC)
  •   Support Daylen (talk) 23:49, 1 February 2022 (UTC)
  •   Support Hampcky (talk) 15:33, 2 February 2022 (UTC)
  •   Support Sabelöga (talk) 16:33, 2 February 2022 (UTC)
  •   Support Weakish support, but it would be good to have something readily available. ~ Amory (utc) 20:30, 2 February 2022 (UTC)
  •   Support WikiAviator (talk) 10:03, 3 February 2022 (UTC)
  •   Support β16 - (talk) 10:36, 4 February 2022 (UTC)
  •   Support Sir Proxima Centauri (talk) 09:43, 5 February 2022 (UTC)
  •   Support Exilexi (talk) 18:19, 5 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 06:07, 6 February 2022 (UTC)
  •   Oppose: the issue can be quite technically nuanced (in wikitext terms) and I don't want newbies to be stopped from making contributions based on something an experienced editor with the page watchlisted can fix. We have a lot of social problems on en.wiki with accessibility being widely misunderstood, undervalued and arcane, but I do not believe these problems can be solved through technical redesign. People just ignore warnings that they don't understand. — Bilorv (talk) 11:07, 6 February 2022 (UTC)
  •   Oppose per reasoning from Bilorv. And this adds extra hurdle to overcome in editing, when the user is unaware of how to resolve the issue. — DaxServer (t · c) 12:04, 6 February 2022 (UTC)
  •   Support Tom Ja (talk) 18:29, 7 February 2022 (UTC)
  •   Oppose this is saying "apply secret sauce to everything" while secret sauce generally just doesn't deal with the complexities of our content in my experience. —TheDJ (talkcontribs) 18:32, 7 February 2022 (UTC)
  •   Support From the experience of Special:LintErrors correction, it can be very difficult to find a problem. Many users can't even fix it. But a built-in tool for this like LintErrors would be interesting. Sunpriat (talk) 00:27, 11 February 2022 (UTC)
  •   Support Fatt-1 (talk) 09:15, 11 February 2022 (UTC)