Also, above, I used the term "deuteranomaly" when I meant "deuteranopia". I mistakenly believed they were describing the same type of colorblindness, but they are two different types.

Possibly this should really be three dimensions (Size, Contrast, Color Correction).

See T12060#213081 some end notes and followups.

See some additional discussion in T12172. Briefly:

T5701 describes a strategy for Pygments styles. I don't think we should tackle that as an accessibility issue, but I think building it as a user preference issue is reasonable.

:/ colors are hard. From my end, I'm very happy with what I ended up doing in Stylish (and this conversation helped, thank you) so it's not as pressing for me anymore. But LMK if there's anything I can help test out.

Basically, can we support "Large Fonts" and "Colorblind Diffs" at the same time?

if td.new-full just used td.new's background color instead (#eaffea). I think it's because:

Based on http://enchroma.com/test/result/medium-protan/?completed=1&summary=moderate+protan&axis=3.11&exta=87.34&extb=4.85&lcs=5.69, I have protanomaly (TIL!)

So I took another look today. Given that the syntax colors are hard to change, looking only at the 4 bg colors I realized that the main change that would help is if td.new-full just used td.new's background color instead (#eaffea). I think it's because:

No problem, we're not in any rush.

(by the way @epriestley I haven't forgotten; some things have come up but I'll try to get back to you this weekend!)

Yes, the rest of the tag is good. I just don't want pinch-to-zoom to be disabled.

Oh, sorry, you just wanted maximum-scale removed.

Here are some screenshots of Phabricator with this tag removed, as you suggest:

I'm not asking you to implement a new accessibility feature, I'm asking you to stop *preventing* an accessibility feature from being used. Browsers already do this; you just need to stop telling them not to.

As you might already have guessed, this isn't a bug.

T12089 has a narrower description with some screenshots, I think the behavior got flipped by accident.

At least one user over email (and I think @epriestley also) mentioned the light highlighting of full lines is hard to distinguish / understand as full change in diffs. I'll look more into these issues before next release is cut.

They said it's a definite improvement. Nice!

Thanks for the quick response! I'll send that last image over to our user, and see if it's an improvement for them as well.

This doesn't appear to be a bug report or a feature request. We don't take design feedback as tasks. If you'd like to weigh in on the design, please comment on the diff or use alternative support resources like Conpherence and Ponder as listed in Support Resources.

...which takes us back to accesskey...

In the future, we might reasonably want to put tabindex="1" on the first input on form pages, like the "Edit Task" page, so that you could press tab once to quickly begin editing. If we put tabindex="1" on global search, the cost of making this change in the future will be much higher.

Good point, thanks for research. I was looking in some notes from research done several years ago, thus obviously no longer accurate.

Can you substantiate "f" being "typically used"? Here's what I see in use in the wild from a quick survey of popular sites and software:

Those are all about preferences and JavaScript handling...

This feature has a tiny impact and a huge support cost.

I don't see anything relevant there actually, could you please elaborate?