Page MenuHomePhabricator

Increase text contrast for better accessibility, in a few places
Closed, ResolvedPublic

Description

The text in a few places, has insufficient contrast to be read by anyone with accessibility problems.
(I.e. Old people (statistically likely to develop cataracts), folks with other eye problems, anyone with imperfect hardware (particularly old monitors), and anyone whose screen is in bright sunlight (whether desktop or mobile)).

Text (that anyone might need to be able to read) must pass WCAG AA-rating at minimum. (4.5 : 1 ratio)
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
Exact values can be calculated with this tool
http://webaim.org/resources/contrastchecker/


The specific issues include:

  • Footer text. This is #92969D text on a #EBECEE background. -- (2.51 : 1 ratio, so it's far under minimum)

Class=phabricator-standard-page-footer. As seen here, which includes important legal information

  • <blockquote>. These are #6b748c text on a #f8f9fc background. -- (4.43 : 1 ratio, so almost minimum. But still frustrating for many people to read, and are used frequently.)

E.g. this text.

  • Some Timestamps. These can be #6b748c on a #CDCFD3 background. -- (3.95 : 1 ratio, so quite a bit under minimum.

Class=phui-timeline-extra, when seen outside of a comment, e.g. above and below here.

  • other?

(Originally filed as https://phabricator.wikimedia.org/T628 and https://phabricator.wikimedia.org/T62)

Event Timeline

quiddity created this task.Dec 19 2014, 8:38 PM
quiddity raised the priority of this task from to Needs Triage.
quiddity updated the task description. (Show Details)
quiddity added projects: Design, Wikimedia.
quiddity added subscribers: quiddity, qgil.
chad added a subscriber: chad.Dec 19 2014, 9:01 PM

I don't know how long the current design of Phabricator will last. It's already deviated from the .org screenshots and those went up only maybe 4-6 weeks ago. In general, we prefer to move quickly and improve Phabricator every week.

My concern in addressing individual complaints on something minor as an individual color is it will open up a long string of nits and picks of the UI, which take considerable time to design, build, and then defend each time.

Is there any issue if I close this as WONTFIX but with the understanding that the contrast and accessibility of the UI will always improve in the future?

Also, it's very easy for individual installs to alter their colors. These are held as constants in src/applications/celerity/CelerityResourceTransformer.php.

I'm also semi curious, since we have the transformer, if we should just provide a 'high contrast' option in user preferences.

It would be easier for us to motivate changes like this if specific users weighed in and said "I personally have difficulty reading text X, and it would be helpful if it was higher-contrast", versus "text X does not conform to standard Y".

In the downstream, https://phabricator.wikimedia.org/T628 seems fairly adversarial and not really rooted in trying to solve a problem which anyone is actually experiencing (in particular, saying "so far nothing was achieved", "Nemo has already verified that it would likely continue to achieve nothing" and "the upstream does not care" about T4843 seems very unfair to our response).

https://phabricator.wikimedia.org/T62 is also relatively adversarial ("Tasks are very hard and ugly to read") and nonspecific. This isn't feedback we've received in general, and the user filing the task isn't motivating their issues with any sort of accessibility concern.

In particular, OSX (and, I think, Windows) include tools to increase contrast with the system. I'd expect users who have difficulty with low contrast color combinations to use these tools (and other tools like zoom, screen readers, inverted colors, etc) because most sites are not WCAG AA compliant. For example, bumping the contrast setting up about half a notch on OSX looks like it's pretty effective in raising the contrast for block quotes and footer text without significantly affecting the overall design of the page.

It would be much more compelling to us to hear something like "I have cataracts, and use the web with setting X in my OS and setting Y in my browser to help me read things, but <some specific thing> is still really hard for me to read under these settings." than "WCAG AA says this is bad".

At a previous job, I spent a substantial amount of time making various web properties conform to WCAG for government-related regulatory/compliance reasons. In this role, I never actually interacted with any users who had accessibility concerns: we were tasked with complying with the letter of the law, not actually solving a real problem. I'd like to avoid that approach in this project.

Basically, we'd like to prioritize things which are most helpful for the largest number of users. At the present time, it sounds like this might not actually affect any real users, since none of the users on the linked tasks appear to experience any accessibility issues.

It would be easier for us to motivate changes like this if specific users weighed in and said "I personally have difficulty reading text X, and it would be helpful if it was higher-contrast", versus "text X does not conform to standard Y".

There is indeed a lot of discussion about standards and user testing in the downstream bug, but I think the most relevant point is Nemo_bis stating, about the footer:

I have perfect vision and this text is hardly readable.

In addition, from a recent discussion on IRC about this subject:

<wctaiwan> The the light grey on dark grey with thin italics for quoted text is just really hard to read.
<Isarra> I can't even read the quoted text without moving my head down so it becomes darker.

I think the blockquotes are also the largest concern, as they are essential for participating in a conversation. The footer might contain legally relevant information, and is therefore also of some concern.

qgil added a comment.Dec 19 2014, 10:13 PM

About the footer, it is worth noting that Wikimedia's instance has a footer, while here you don't, and most existing instances don't have one because it is a relatively recent feature. The fact that the site with a footer gets this feedback has some relevance.

I personally don't have much problems reading it, but I can understand other users wondering whether it could have a slightly higher contrast.

Thank you immensely, for these rapid changes!
Feel free to close this bug, now that the most pressing issues have been resolved.

2 quick addendums:
On "standards-compliance", I agree that 100% compliance for the sake of 100% compliance is generally unnecessary, and that context-is-key. (This is why I didn't attempt an exhaustive list of all the lighter text elements. Most people don't need to read "Via Conduit", so it can remain at the edge of accessible indefinitely). The standards exist mainly to give scientific benchmarks, which can better enable discussion about how to meet the needs of people who are less-likely to speak up for themselves (due to their statistically smaller set), in instances where it is important that everyone be able to read everything.
On the tone of comments at the downstream bugs, I should note that there has been quite a lot of very-recent disagreement, on issues of text-contrast. We've historically (for over a decade) had "black text almost everywhere", and some recent changes and software-extensions have used some subjectively too-light-a-grey text in various places. Additionally, a large part of the editor demographic are in or near retirement age, and so tend to be more impacted by interface elements that are at-all-hard to read. They don't always complain themselves, hence people like me with great vision (unless the sun is directly on my screen!), take up the accessibility torch on their behalf. TL;DR: accessibility discussions have been somewhat heated, of late. I'm sorry that heat got transmitted in the wrong direction.

Again, thank you. :)

chad closed this task as Resolved.Dec 22 2014, 5:02 AM
chad claimed this task.

Thanks!