Archives

Archive 1 Archive 2 Archive 3 Archive 4

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

Hello,

This is Amal Ramadan, the Sr. Community Relations Specialist supporting the Wikipedia mobile apps team.

Our Android team is working on Image Recommendations that will enhance accessibility and user engagement within the Wikimedia mobile apps; our engineers are adding a new lint error type, which is planned to match images without alt text and are expected to trigger on a large number of pages.

It is planned to use this lint category to feed both existing linter-based correction workflows and a "microtask" workflow in the Wikipedia mobile app, where small work tasks can be presented to users in a relevant context.

We want to make sure this won’t be disruptive to existing linter system users and that updates to support the new lint type can be coordinated.

Our current technical evaluation doesn't expect performance problems from this, but if it's overloading people's workflows, we want to be sure to accommodate those needs.

Thank you for your understanding and cooperation as we work towards enhancing the Wikipedia mobile app experience. ARamadan-WMF (talk) 08:10, 27 February 2024 (UTC)[reply]

In what way is missing alt text a Linter syntax error? Can it break the page rendering in some way? Like the wide tables, I think that tracking this condition would be a misuse of Linter. A tracking category should be used instead. Unless I am misunderstanding the description. – Jonesey95 (talk) 14:38, 27 February 2024 (UTC)[reply]

Also, per Wikipedia:Manual of Style/Accessibility/Alternative text for images, An image that is purely decorative (provides no information and serves only an aesthetic purpose) requires no alternative text. (See also MOS:BLANKALT.) Tracking such images in some way would lead to many false positives, probably millions of pages, in this category. Have you analyzed a database dump to determine how many pages would be affected by this proposed new tracking?

You have not linked to any pages that show how this tracking would happen, or which namespaces would be tracked, or whether an empty |alt= would be tracked or not. Please show your work. Once you have a basic specification, you should bring this up at one of the Village Pumps here at en.WP, not at this page, since Linter should not be involved. People at the Village Pump will be able to give you helpful feedback. – Jonesey95 (talk) 14:40, 27 February 2024 (UTC)[reply]

Yeah also as a screen reader user I don't think adding alt text is really a task that random new mobile users should be doing, especially given edits I've noticed already on my watchlist from this kind of cohort. My initial mental ballpark figure for the number of people who'd get it right (i.e. produce something minimally useful) would be around 1%; maybe that's a bit harsh, but I'm sure it would be way less than 50%, and such an error rate (especially for text that most Wikipedia readers won't read at all) would be completely unacceptable. This is the short description problem all over again. I know adding alt text is becoming more mainstream these days in some quarters (which can only be a good thing), but compared to most sites, Wikipedia's requirements about it are ... more than a little bizarre. Something like "Refer to caption" as default alt text for thumbnail images would be infinitely easier to implement and more useful than what's being proposed above. Graham87 (talk) 15:32, 27 February 2024 (UTC)[reply]

Hello @Graham87,

Thank you for the good high-level feedback for the high-level feature, It's passed to the engineers who are working on this. ARamadan-WMF (talk) 08:47, 7 March 2024 (UTC)[reply]

@Graham87

Hi everyone, sorry for the confusion. The project page for this effort is actually here. By the way my name is Jaz, I am the Lead Product Manager for the apps. @Graham87 I fully agree that it is important to be intentional that in our effort to address the 95% of images that do not have alt-text on Wikipedia, but that in our quest in creating a more equitable experience for low vision folks and folks with low bandwidth where images do not load, we do not replicate the issues we see with 3% of images that do have alt-text. Our goal is to increase the 2% of helpful alt-text. As you’ll notice in our consultation strategy, we've brought a prototype to the GLAM conference and gathered our first round of feedback from volunteers in attendance regarding a prototype ; I welcome you to try it out. The insights were positive but there is a lot more careful testing we need to do before moving forward, which is what we are working on at the moment. All of our work is being done in lockstep with an Accessibility organization based in Latin America, our initial target audience are folks in Latin America and the Caribbean speaking French, Spanish and Portuguese. Starting out the feature will only be available for people with at least 50 unreverted edits, a measure we introduced for all app Suggested Edits including Article Descriptions in 2022 based on community feedback. We partnered with several community members to evaluate if there was an increase in the quality of suggested edits and did see a lift by adding that gate, although I am always happy to partner on improvements. The Suggested Edits project page will receive an update next week with additional details about the next phase of our experiment now that we've gotten feedback about the prototype. That update will also include an updated decision matrix for the next phase of this experiment. I will ensure Amal tags you on the talk page when the update is there so that you can review our decision matrix and contribute to other guardrails we can put in place to ensure this experiment is meaningful in deciding if we should proceed. The questions that @Brooke Vibber (WMF) and @ARamadan-WMF are asking about the Linter is to investigate if using the linter is a promising use case for providing a feed of contextualized alt-text in the case we have positive indicators. This investigation is not to convey that we are definitively rolling this out. I also want to assure you that this is a true experiment, it will be turned off after some people try the tool. We will evaluate the usefulness of what is produced in partnership with an accessibility organization before we proceed and will not leave the tool on while we make decisions. If you'd like to be apart of the evaluation process, I also welcome your partnership when we get to that stage! I've also created this thread to continue to discuss the project itself if you're interested. JTanner (WMF) (talk) 00:45, 8 March 2024 (UTC)[reply]

Hi@Jonesey95,

It's a pattern in the syntax that indicates something was left out that belongs according to standards.

Can it break the page rendering in some way? yes, those images have no alt text.

Mentioning the wide tables is something not specific to this issue; if you wish you help us can you elaborate more with what, specifically, would be inappropriate for the linter and why?

And, a tracking category does not carry markup location or list which image was affected, so does not provide us the information we need.ARamadan-WMF (talk) 08:40, 7 March 2024 (UTC)[reply]

Hello again @Jonesey95,

As noted we already expect a large number of matches, this is expected and will not be surprising. What we want to know is whether that will cause disruption to existing workflows using the linter data.

We've got code, which is even better. :) We already talked to the people who wrote the linter and wrote code that they have reviewed; we want to know about people using the linter to ensure that it would not cause disruption to workflows using the linter error data via special page or API.Thank you! ARamadan-WMF (talk) 08:44, 7 March 2024 (UTC)[reply]

The answer is YES, it will cause disruption to our Lint-fixing workflows, as the "wide table" tracking did. Please do not add this tracking to the Linter tables or to the Linter section of the Page information page. We had to modify all of our reports and filters and queries, and the LintHint tool, to exclude the "wide table" tracking, since it is not a Linter syntax error. Please use a tracking category. If you want editors to see the location of the error, you can use an error message in the edit preview to show the location of the error message, as Module:Check for unknown parameters does.

Also, you have not addressed my excerpt from the accessibility page above, which specifically says that some images do not require alt text. – Jonesey95 (talk) 14:24, 7 March 2024 (UTC)[reply]

Empty |alt= parameters is not a sounding like a lint issue, as it is not broken syntax, just is an unfilled parameter. I agree with the above replies and strongly request you do a tracking category instead of a lint category as this is sounding much worse than the big tables where action was *mostly* not needed and was rather annoying to deal with. WP:LINT is for things that break a page or don't display correctly on a page. It is not for "user experience inconvenienced" tracking. Please reconsider and change to a non-Lint tracking category if possible, and leave Lint out of this plan. Thank you. Zinnober9 (talk) 01:45, 28 February 2024 (UTC)[reply]

Yeah and another thing I thought of is that the people who'll be most affected by this (i.e. screen reader users) have an additional barrier to edit because of the inaccessible CAPTCHA. Graham87 (talk) 03:25, 28 February 2024 (UTC)[reply]

Screen reader users by definition are unable to perform this task because they cannot view the image.

Please elaborate more if you mean another thing. Thank you. ARamadan-WMF (talk) 09:06, 7 March 2024 (UTC)[reply]

@ARamadan-WMF: Screen reader users are pretty much the only people who'll see alt text. So if a new user adds "Pooppooppoop", "Buy my wears at amazingsite.com" or, even worse, completely wrong alt text (and it's not detected by the regular anti-vandalism filters, which for less obvious examples it may well not be), the only people who'll be directly affected are screen reader users and they'd face extreme barriers to correct the wrong alt text. Please discontinue this feature idea ... just ... nobody needs this ... and as other people can probably attest, I'm not usually this blunt about these sorts of issues. Graham87 (talk) 09:29, 7 March 2024 (UTC)[reply]

I commented at T344378 on Phabricator. Graham87 (talk) 09:47, 7 March 2024 (UTC)[reply]

Your comment is delivered on the Phab. ticket; thank you. ARamadan-WMF (talk) 09:58, 7 March 2024 (UTC)[reply]

Thanks for your feedback Graham87 -- it seems that you have some specific opinions on what kinds of markup patterns are suitable for the linter warnings/errors list and which aren't that aren't shared by the WMF Content Transformers team that maintains Parsoid, and that there's some history here about the linter in Parsoid that you, and perhaps others, have strong feelings about. We're happy to put the data elsewhere if that helps keep your existing workflows clear.

As for the general high-level feature feedback, that's useful too and will be passed on. Editing an encyclopedia is not an "easy" or "trivial" task, and never has been, and none of these things are expected to be possible without guidance and documentation for the user.

On the specific issue of empty alt text -- that can be explicitly signaled by setting alt= which will emit an empty, but present, alt text attribute. --Brooke Vibber (WMF) (talk) 16:29, 7 March 2024 (UTC)[reply]

It might be helpful for someone to link to a set of sample pages that would and would not trigger this tracking, or to the programming specification that will determine whether a page is flagged by this check for missing alt text. The initial description at the top of this section says "images without alt text". Some people might interpret a blank |alt= as "without alt text", even when it is a deliberate choice. A detailed spec would help to clear up such differing interpretations. Without a specification, we end up with unresolved parent tasks like T274382. Honestly, I would rather see programming time spent on fixing actual bugs like those listed in that task, instead of new features that will lead to more bug reports and more work for editors. – Jonesey95 (talk) 16:43, 7 March 2024 (UTC)[reply]

Hello @Zinnober9,

This is a very good comment; but a tracking category would not provide the information we need on location and file. Most likely we'd create a rough duplicate of the lint errors record and linter API feature just to record "something that's not a markup error but is a markup issue that can be caught algorithmically and recorded for human review" :) ARamadan-WMF (talk) 09:04, 7 March 2024 (UTC)[reply]

Wikipedia:WikiProject Texas Tech University has no lint error but it obviously has a broken layout. Can't figure out how to fix this. Gonnym (talk) 11:50, 3 March 2024 (UTC)[reply]

Now fixed. Gonnym (talk) 12:37, 3 March 2024 (UTC)[reply]

The Wikimedia Foundation Web team is currently working on a dark theme for Wikimedia projects and soon Wikimedia skins will support two color schemes.

This has implications on user-generated content which in the past has made understandable assumptions about how the content will be displayed. For example in the past, if text was given a yellow background the assumption was made that the text color would be black. In dark mode where the text will now be white, this creates accessibility issues.

While the Web team is aiming to minimize the work required by editors in the short term, this work has flagged a long-term need for lints to help editors locate pages with accessibility issues. Next week, we will add a new linting rule to flag pages which we have identified as problematic. To minimize disruption this will be initially hidden as we iron out any problems. The Web team has provided a set of recommendations to support this work.

In addition to this and to reduce the burden new lint rules can cause to the community workflow, we are working with the Content Transform team on T334527  so that community adoption/acceptance of lint rules in future can be done separately from the creation of them. We are documenting this on mediawiki.org.

Please let us know about any questions or concerns you have by replying here. You can also raise bugs by creating a ticket in https://phabricator.wikimedia.org/project/view/6717/.

Thank you! Jdlrobson (talk) 17:07, 14 March 2024 (UTC)[reply]

I'm wondering how signatures with colors will work with the dark theme and if they will be flagged by the linter. Gonnym (talk) 17:29, 14 March 2024 (UTC)[reply]

Jdlrobson, thanks for the note, the links, and the process improvements. Are there instructions anywhere explaining how to turn on this new night mode so that we can see if the lint-flagged condition really causes a problem? That might help us determine if the lint condition is flagging any false positives. I also have a question similar to Gonnym's: many signatures use code like font color=black or span style="color:black" to color text, with no specified background color. Will those signatures be flagged by the new linting rule? If so, I foresee a LOT of errors. – Jonesey95 (talk) 18:00, 14 March 2024 (UTC)[reply]

If they are flagged, how will they interact with the new rule that doesn't allow lint errors in signatures? Gonnym (talk) 18:32, 14 March 2024 (UTC)[reply]

Those will not be flagged for now. Right now we are only flagging the case where background is defined without a color.

Those will be an issue with the night mode feature however.

You can test night mode (for time being only working on mobile) by appending ?minervanightmode=1 or ?vectornightmode=1 on any URL. Jdlrobson (talk) 19:54, 14 March 2024 (UTC)[reply]

Jdlrobson, it appears that signatures are indeed being flagged by this new Linter rule. Is this intentional? See this VPT post. – Jonesey95 (talk) 16:41, 22 March 2024 (UTC)[reply]

Also, the Linter rule appears to have errors detecting nested span tags. See T360797 and mw:Talk:Reading/Web/Accessibility_for_reading#Signature_disabled, two related cases. – Jonesey95 (talk) 16:56, 22 March 2024 (UTC)[reply]

Was wondering that too. I will say though that I regularly use a dark mode browser addon (Dark Reader), and any black text is displayed as white, so curious if that will be a similar thing with this Wikipedia setting, or if black = black in all cases. The addon I use does make some color combos that look fine in light mode turn hellish in dark though; cyan backgrounds almost always are hell with this as it leaves the cyan background alone, but turns the darker text shades to a lighter (inverse?) color and the combo becomes unreadable. In those cases I've had to turn it off to preview those pages I'm fixing. Zinnober9 (talk) 23:10, 14 March 2024 (UTC)[reply]

Related discussion at Template talk:Episode list#Accessibility problems with this template in night mode (also by Jdlrobson).

Some TV related templates that use colors that should be tested they aren't producing lint errors:

• Template:Episode table
• Template:Episode list
• Template:Infobox television season
• Template:Series overview

Gonnym (talk) 06:45, 15 March 2024 (UTC)[reply]

Probably most sports navboxes which already violate color will also appear on this list. Gonnym (talk) 17:34, 17 March 2024 (UTC)[reply]

@Jdlrobson, see mw:Talk:Reading/Web/Accessibility_for_reading#Signature_disabled. Sdkb ^talk 16:16, 22 March 2024 (UTC)[reply]

How much attention should be paid to this new tag?[edit]

I am finding it challenging to determine how much attention to pay to this new tag. When I am logged out, the code to force vector night mode results in a bunch of black-on-black and blue-on-black text for me (example: John Dalton), except, ironically, in elements like navboxes and message boxes, many of which trigger this new Linter rule. Those items show in "regular" mode, with white backgrounds, not anything like "night" at all.

I posted a note to Template talk:Navbox with some thoughts about that template's triggering of this new rule. It is unclear to me whether something actually needs to be fixed, because when I force night mode, everything on the page looks terrible except for the element that is supposedly out of conformance. Because of my inability to make night mode function reasonably, I have no way to test whether adding an explicit color declaration does anything useful. I feel like I'm missing something. – Jonesey95 (talk) 05:23, 23 March 2024 (UTC)[reply]

The night mode for Vector 2022 hasn't been built yet. It will be built over next 4 weeks in an identical fashion to Minerva. We are releasing the lint error so editors get a head start on fixes. ?vectornightmode=1 is therefore not the query string to use. You need to use Minerva for now e.g. https://en.wikipedia.org/wiki/John%20Dalton?minervanightmode=1&useskin=minerva.

You can also add the following to Special:MyPage/minerva.js to force night mode on for all pages (e.g. template namespace)

(function () {
   const c = document.documentElement.classList;
   if ( c.contains( 'skin-night-mode-page-disabled' ) ) {
     c.remove( 'skin-night-mode-page-disabled' );
     c.add( 'skin-theme-clientpref-night' );
   }
}());

🐸 Jdlrobson (talk) 06:00, 23 March 2024 (UTC)[reply]

Also here's an example of a fix: https://en.m.wikipedia.org/w/index.php?title=Grand_Slam_(TV_series)&diff=1215109361&oldid=1203322851&title=Grand_Slam_%28TV_series%29&diffonly=1

From what I can see the lint rule is working as expected. 🐸 Jdlrobson (talk) 06:01, 23 March 2024 (UTC)[reply]

Thanks for the Minerva tip; I was just applying the instructions you gave above and was confused. That Minerva string works on the John Dalton page, but when I go to https://en.wikipedia.org/wiki/Template:Bolvadin_District?minervanightmode=1&useskin=minerva or https://en.wikipedia.org/wiki/User:Jonesey95?minervanightmode=1&useskin=minerva I see a regular look. What am I missing now? – Jonesey95 (talk) 13:23, 23 March 2024 (UTC)[reply]

There is rule in Minerva to mitigate breakage: [style*="background"] elements get set to a black color with !important. The hope is to eventually remove this when the lints are fixed. You can disable this rule in developer tools if that is helpful. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)[reply]

Also see my script above to force it on for other namespaces. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)[reply]

bgcolor[edit]

Using bgcolor in a table doesn't trigger the lint rule. It's only seems to be triggered by background in the style attribute.

{| class="wikitable"
|bgcolor="yellow"|test
|}

-- WOSlinker (talk) 13:01, 1 April 2024 (UTC)[reply]

good point. I thought bgcolor was already covered by Special:LintErrors/obsolete-tag but I guess that only applies to HTML4 tags not attributes? 🐸 Jdlrobson (talk) 00:46, 2 April 2024 (UTC)[reply]

If these attributes are also obsolete they should probably be tracked by the lint. Gonnym (talk) 12:47, 8 April 2024 (UTC)[reply]

Links related to the above section: See Special:LintErrors/night-mode-unaware-background-color and mw:Help:Lint errors/night-mode-unaware-background-color. The relevant feature creation task was T359205.

I don't have time to work on anything related to this in the next week, but I am putting some links here in case people are wondering why many of the reports changed today. Queries may have to be adjusted, or maybe these conditions might be easily fixable in a few templates. I don't know, since I haven't really looked at it yet. – Jonesey95 (talk) 16:17, 22 March 2024 (UTC)[reply]

From an initial poke around, it appears that many or all of the templates listed at {{Table cell templates/doc}}, as well as {{navbox}} and {{ombox}} and probably similar boxes are affected by this new tracking tag. I expect that a systematic fix for some of these sets of templates will be a better path than simply adding a text color specification to each template. – Jonesey95 (talk) 16:37, 22 March 2024 (UTC)[reply]

Hey there I was curious to hear from people who have used Help:Lint_errors/night-mode-unaware-background-color

I have a few questions

1) How: Forgetting the "why" these need to be fixed, when interacting with the lint rule is it clear what to fix and how to fix it? If not, how could we improve it?

2) Why: How can we improve the documentation over on Help:Lint_errors/night-mode-unaware-background-color to make it clearer why these are important to be fixed?

3) What would need to happen before we could consider promoting this rule so it is not hidden?

Thanks in advance for your feedback! 🐸 (accidentally posted under volunteer account) Jon (WMF) (talk)

Answering 1 and 2. I have found that "color:inherit" seems to work sometimes and break things other times. It is not clear to me why that is the case. Better guidance around when it is safe to insert "color:inherit" might help. When that string does not work, it is not clear what to do. Inserting "color:black", for example, seems counter to letting dark mode pick an appropriate color, but maybe not.

Answering 3. Please refer to the discussion above. Feedback from WMF folks like The night mode for Vector 2022 hasn't been built yet and There is rule in Minerva to mitigate breakage: ... You can disable this rule in developer tools if that is helpful was helpful to me, in that it helped me to understand that this new Linter rule was not ready for me to work on yet. To be able to work on it, I would need a way to look at a page in Vector 2022 (the default skin) using dark mode, see the breakage, and then apply changes and look at them in preview to see whether the problem is fixed. AFAIK, I can't do that yet.

More answers to 3. Jdlrobson has been doing good work around the site to update templates that need fixing. That work is necessary to clear out the vast majority of tracked pages, which have tracking assigned to them by templates such as {{navbox}}. I don't think the rule should be promoted until the template space is largely free of tracked pages and pages affected by transcluded templates have been null-edited to remove them from the lists. – Jonesey95 (talk) 02:31, 19 April 2024 (UTC)[reply]

Answering 2 specifically: Here's an example of where "color:inherit" did not work for me: I tried applying it next to every instance of a background color at {{2008 NHL Entry Draft (WHL draftees)}}, and it turned the "show/hide" links black instead of using the default blue for links. Using "color:black" had the same effect. Not good. I have exhausted the advice in the "How to fix" section of the Help page. What should I have done? – Jonesey95 (talk) 04:22, 19 April 2024 (UTC)[reply]

You are thinking about this correctly. In your example the correct fix would be setting color to something black.

And yes.. this does make the show/hide links black. Previously they were inaccessible in that page when they are blue and the associated code will transfer color to the element. While I think the UI could be improved here (perhaps an icon would be better) at least they are now readable to 100% of people regardless of disability. If you have concerns around the resulting UI it would be worth filing a bug about that. 🐸 Jdlrobson (talk) 14:54, 20 April 2024 (UTC)[reply]