Grants talk:IEG/Color blindness content checker

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

A great idea[edit]

Dispenser, I really like this idea. I would be happy to sign up as an advisor and help with carrying out the project. I also recommend a similar endeavor for English Wikipedia, regarding infobox color schemes and the like. harej (talk) 02:56, 3 May 2015 (UTC)

Harej, there are several open source software packages for simulating color blindness, both multiplatform executables and web based. The goal is not to duplicate existing tools, but to identify which of the 25 million images on Commons has issues with color blindness. Context is also important: The official MTA colors for the NYC Subway signage are problematic, but represents the real world and so should be tagged differently from a map that encodes information using color. Ideally every non-gray scale image should contain the importance subjective importance of color and a suitable alternative description (Alt text). However that's beyond the scope of this proposal which is an automated tagging of maps and diagrams. Dispenser (talk) 17:59, 3 May 2015 (UTC)
After struggling to write the pitiful amount of text, I think I should take you up on your generous offer, Harej. Dispenser (talk) 02:13, 5 May 2015 (UTC)

9/29/15 Proposal Deadline: Change status to 'proposed[edit]

Hi Dispenser,

This draft is looking like it's well on its way. I'm writing to remind you to make sure to change the status of your proposal from 'draft' to 'proposed' by the September 29, 2015 deadline in order to submit it for review by the committee in the current round of IEG. If you have any questions or would like to discuss your proposal, let me know. We're hosting a few IEG proposal help sessions this month in Google Hangouts. I'm also happy to set up an individual session. Warm regards, --Marti (WMF) (talk) 20:31, 20 September 2015 (UTC)

More about your experience?[edit]

This idea is interesting. It helps in the area of accessibility, it can probably rely on existing tools and libraries, and the outcome proposed is very specific. There is no reason to think that you lack the skills or experience to go ahead with this project, but you are not providing much information. I checked the link provided to your user page and did a quick search in Phabricator, and couldn't get much. It would be useful if you could link to tools you have created, repositories with code you have written, or something along these lines.--Qgil-WMF (talk) 19:57, 2 October 2015 (UTC)

Perhaps you looked in the wrong places? Dispenser definitely doesn't need introduction. :) Try c:User:Dispenser; his tools were used by thousands users I think, before the assassination of Toolserver. Nemo 21:04, 2 October 2015 (UTC)
(Part 1) I built a prototype of automated portion of the tool using existing libraries, the problem encountered were: Gamma was implemented wrong, HSV/HSL isn't accurate enough, and arbitrary segmentation (groups at 0-63, 64-127, 128-191, 192-255) was too course. Nothing that can't be overcome.
(Part 2) Tools are alive on my own machine and seeing significant usage with assisting a over dozen in 500+ edits per day. The tool that will serve as a reference is Dab solver which users progress and provides many extra not seen in other disambiguation tools. Dispenser (talk) 20:56, 6 October 2015 (UTC)

Eligibility confirmed, round 2 2015[edit]

IEG review.png

This Individual Engagement Grant proposal is under review!

We've confirmed your proposal is eligible for round 2 2015 review. Please feel free to ask questions and make changes to this proposal as discussions continue during this community comments period.

The committee's formal review for round 2 2015 begins on 20 October 2015, and grants will be announced in December. See the schedule for more details.

Questions? Contact us.

Marti (WMF) (talk) 02:20, 4 October 2015 (UTC)

Itemized budget and more success measures[edit]

I think this is a very worthwhile project, but I would like to see an itemized budget, given the size of the request. How many hours per week, per paid project member, at what rate? Estimates are fine; the point of an itemized budget at this stage in the process is to demonstrate that the project leaders are thinking ahead and scoping things reasonably, not to force them to commit to any arbitrary numbers. I also think that this project needs more measures of success. For example, since you're budgeting for a "user tester", it would be reasonable to include some success measures that relate to demonstrating that the tool works the way it should, for the users and use-cases you've identified. Cheers, Jtmorgan (talk) 19:41, 7 October 2015 (UTC)

Comments[edit]

The "endorsements" section implies that one endorses the project, so I'll place my comments on this discussion page instead.

A fundamental question is how prevalent is this problem. That's not just a question of 8 percent colorblind but also how many images have problems. There's no question it is a problem, but how many images on WP are at issue? Is this proposal the best way to find them?

The statements and goals are also vague.

The proposal is fractured. The first image is a fruit stand, but continuous images are not the focus of proposal. Another image is the girl on a rope. One cannot reasonably change the color palette of a photograph; we are stuck with it.

  • "Automated tool to identify images that pose a problem for colorblindness"

The proposal does want to focus on "charts and diagrams", but it does not suggest a method for automatically finding such charts and diagrams. That's a huge hole. It suggests "Write image scanner program", but there are no details.

PNG files may be images or charts and diagrams. In contrast, most SVG images will be a chart or diagram.

PNG files that have a limited range of color pixels are probably charts or diagrams. A relatively simple program can compute a color histogram of a bitmap image. Say a color palette with less than 16 colors is a candidate for being a chart or diagram. One can then look at the en:color difference of the palette colors. The proposal does not suggest any background in computing color differences for different color vision deficiencies.

Although a reasonable heuristic, it does not work in many cases. Many diagrams now have gradient fills, so they would not be detected by such a simple algorithm. Are gradient fills common enough to provide significant confusion?

SVG files are probable charts or diagrams. A simple approach might look at a PNG rendering of an SVG file, but such a color histogram will also be confused. SVG rendering uses anti-aliasing algorithms, so the color palette will have many colors even if there are no gradient fills.

Consequently, the examination of an SVG file should probably be done on the XML. Skill/familiarity with parsing SVG should be explicitly described. Some colors are in styles or sheets.

  • Address images that intentionally fail

There are some images that may want to keep color deficiencies; eg, :File:NYCS-line-black-EastPkwy.svg wants to stay that way as an illustration of color confusion. Such files need a tag so they don't get "fixed"; something similar to the translation tag its:translate="no".

  • More details and better focus needed

This proposal needs more detailed discussion (especially about the link in the See also section), more focussed goals, and better description of proposers skill set. It is not clear what "Research the academic databases over colorblindness" means. Is that a database about journal articles or is it something about RGB values for good color differences? What is an "Observation program"? Is it similar to links in the proposal that simulate specific CVDs? Is it the "Tool to (correct) simulate the different types of colorblindness"?

The proposal needs to be clear but it is not. Simple and concrete goals would be better.

Glrx (talk) 22:43, 16 October 2015 (UTC)

We are not stuck with a photo which has bad colours. In many cases, the photo can be replaced with a better one in the articles where it's used, if only users know there is such a need and possibility. Nemo 14:13, 17 October 2015 (UTC)
Yes, we can choose different images, but the question here is about the proposal. The proposal states:
Write a program that analyses the dominate colors in an image. The program will use the databases from Wikimedias so that the program determines from the histogram to create the dominate colors in the image. The program will select from those databases, information which indicates conflicting for colorblind uses. The information from the histogram will be used to determine from the Wikimedia Foundation databases if there is a conflict for color blind users.
But it does not suggest how such a method would work for pictures. The image will be perceived differently by different subjects, but what characteristic of the histogram suggests that the perceptions are so different that the image needs to be replaced? The proposal does not divulge anything beyond a color histogram. The research topics suggest such insight is absent. The consulting some mysterious "Wikimedia Foundation databases" may sound good, but what are those databases and how could a program use them?
Compare that to a simpler tool that mimics the functionality of some external websites. Display the image side-by-side with a filtered/doctored image. For example, display the two fruitstand images. There's no histogram, there's no database. We can ask editors to pass judgment on the images. Fundamentally, the fruitstand will still look like a fruitstand; the girl on a rope will still look like a girl on a rope. In most instances, we don't care about the color of the fruit or if her clothes are blue or purple.
For technical images, there can be a problem. Map colors may be difficult to distinguish for some viewers. A histogram can be used here, but using a database to determine conflict does not make sense.
Glrx (talk) 17:27, 17 October 2015 (UTC)

Aggregated feedback from the committee for Color blindness content checker[edit]

Scoring criteria (see the rubric for background) Score
1=weak alignment 10=strong alignment
(A) Impact potential
  • Does it fit with Wikimedia's strategic priorities?
  • Does it have potential for online impact?
  • Can it be sustained, scaled, or adapted elsewhere after the grant ends?
6.2
(B) Innovation and learning
  • Does it take an Innovative approach to solving a key problem?
  • Is the potential impact greater than the risks?
  • Can we measure success?
5.4
(C) Ability to execute
  • Can the scope be accomplished in 6 months?
  • How realistic/efficient is the budget?
  • Do the participants have the necessary skills/experience?
5.2
(D) Community engagement
  • Does it have a specific target community and plan to engage it often?
  • Does it have community support?
  • Does it support diversity?
5.0
Comments from the committee:
  • I like to see proposals like this one because it indicates that we are in fact quite successful at illustrating Wikipedia. I like it that the proposer has zeroed in on one Google image that sparked the work, much in the same way that the Rijksmuseum was sparked to contribute open data after being confronted with the "Yellow Milkmaid Syndrome". The impact is high for colorblind readers, but also for anyone who uses Wikimedia material in b&w print (such as teachers in schools)
  • While improving accessibility for color-blind readers is a worthwhile goal, it is not clear that analysis of raw image data will be an effective way to achieve impact in this area, given the concerns that have been raised regarding the relatively small number of images that could potentially be modified to improve accessibility relative to the overall number of images on the Wikimedia projects.
  • Yes, software for detection needs to be developed (risky). Actual work to improve images will be done the wikiway via suggestions to creators/uploaders.
  • There are a number of existing tools that provide the proposed capability, so there does not appear to be significant potential for innovation. Meaningful measures of success still need to be added.
  • Hard to tell whether this proposer can get the job done, but Nemo seems to believe it can be done, and I trust his technical know-how.
  • The budget and implementation plan are lacking in detail.
  • There seems to be support from the mediawiki community outside of Wikimedia itself, and some support on Commons.
  • There is minimal community engagement and support.
  • The tool does not solve the problem but notifies people. The budget seems too high.
  • We need to do more to increase accessibility of what we already have, in addition to efforts to ingest or create new content. Additional checks are important to ensure the content we will create in future is accessible to the most people...
  • I would like to know what people with this color blindness think. I personally have experience that people with some problems of vision have already some configurations and tools to solve these problems while surfing because these problems happen not only in Wikipedia but in all websites.
  • It’s not clear how the budget is calculated. Needs a clearer explanation.

Comment by Glrx[edit]

The Committee feedback is good. The proposer has not addressed the budget issues nor the skill set; both topics raised above. Although Nemo is right that the task can be done, I do not see that the proposer has the needed insight into the problem.

Another issue is that colorblindness is not a single problem afflicting 4.5% of the population. The term encompasses many vision defects, and that reduces (but does not eliminate) the magnitude of the problem. Most of the defects are anomalous 3-color vision (a defective 3-color vision rather than an absent cone leaving 2-color vision) and there is significant sex linkage (8.7% male and 0.4% female). In an anomaly, the a color vision sensor has shifted to a different color band. Anomalies are 6.3% of males; two-color vision are only 2.4% of males. The MTA sign example in the grant proposal is presumably Deuteranopia and affects 1.2% of males 0.01% of females.

A low-tech way of handling this problem is to create a template such as Commons:Template:Colour blind and its category Commons:Category:Images with problems for colour blind people. The category has about 2 dozen images; there's also a subcategory City location maps of Iran (with its own sub). The template could be extended to link to external sites that can run checks such as done by Commons:Template:Valid SVG (clicking runs off-site validator). For charts and graphs, the template could recommend a suitable color palette. See, for example, discussion by Okabe and Ito at Color Universal Design (CUD) - How to make figures and presentations that are friendly to Colorblind people and especially section on "Set of colors that is unambiguous both to colorblinds and non-colorblinds". The Colour blind template currently has unknown internationalization.

Glrx (talk) 22:22, 23 November 2015 (UTC)

Round 2 2015 decision[edit]

IEG IdeaLab review.png

This project has not been selected for an Individual Engagement Grant at this time.

We love that you took the chance to creatively improve the Wikimedia movement. The committee has reviewed this proposal and not recommended it for funding, but we hope you'll continue to engage in the program. Please drop by the IdeaLab to share and refine future ideas!

Comments regarding this decision:
While improving accessibility for color-blind readers is a worthwhile goal, it is unclear how analysis of raw image data will achieve impact in this area, given the concerns regarding the relatively small number of images that could potentially be modified to improve accessibility relative to the overall number of images across Wikimedia projects. We would love to see more engagement with your target user community in any future ideas you have.

Next steps:

  1. Review the feedback provided on your proposal and to ask for any clarifications you need using this talk page.
  2. Visit the IdeaLab to continue developing this idea and share any new ideas you may have.
  3. To reapply with this project in the future, please make updates based on the feedback provided in this round before resubmitting it for review in a new round.
  4. Check the schedule for the next open call to submit proposals - we look forward to helping you apply for a grant in a future round.

Questions? Contact us.