User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/600.4.10 (KHTML, like Gecko) Version/8.0.4 Safari/600.4.10 Steps to reproduce: Tried to implement some accessibility features for low vision people, such as "Bold Text", "Darken Colors", "Text Size", so that people with visual impairments (including senior people) are better able to use Firefox. Actual results: I had to find the places in code where the colors/font sizes/faces/line widths get applied in the code, and then guess the proper (somewhat bigger) value when an accessibility setting is on. I envied the colleagues over at Mozilla who apparently had the exact values they should use for common users specified by a graphic designer, since I had no such specification and had to guess the values adjusted for accessibility by simply making the value "somewhat bigger (darker, bolder, bigger, wider), all by the same bit". Expected results: There should be a UI spec/mockup for each situation with the accessibility settings below applied (just like there is a UI spec/mockup for "normal" UI with no accessibility settings applied) which should specify line widths / different icons, font faces (differ probably only in boldness), colors, font sizes etc. I think it would be sufficient to make a spec for all-in-one scenario, i.e. a user having these turned on: - Larger Text (with Larger Accessibility Sizes, set to some bigger non-maximum size) - Bold Text (which also means bolder borders/icons - see toolbar in Safari) - Increase Contrast - Reduce Transparency (increases contrast) and Darken Colors (also increases contrast, could also mean darker icons) Sometimes try to look at the app with nearly/half closed eyes to perceive the difference. Having an item bigger/bolder/darker can make the difference between user not noticing it is there at all, and at least noticing "something is there" and use VoiceOver/Zoom to touch it and let it read "what exactly is written there". Sometimes it could also make the difference between having to touch the item to let VoiceOver read it (perhaps requiring the user to turn VoiceOver on) or enlarge it with Zoom, and being able to read it without VoiceOver/Zoom. Btw., IIRC, iOS 8 allows icons to be just outlines and colors applied on runtime, perhaps it could allow one icon image to be rendered darker when "Darken Colors" is on (for icons where this would be appropriate)? Perhaps try to use iOS (including Safari) for a little bit of time with all/some of these settings to get the feel. Also perhaps, with these settings, try using Firefox which already has "Bold Text" and "Darken Colors" implemented (even though it is probably a little outdated already; after setting the settings, force quit of Firefox is needed) and check the current state for needed adjustments / omissions. Ideally, every UI mockup/spec should have two versions: 1. "normal", 2. "accessibility" (for all the settings mentioned above turned on at the same time). See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1124848 ""Text size" accessibility setting is not respected" https://bugzilla.mozilla.org/show_bug.cgi?id=1124828 ""Bold Text" accessibility setting is not respected" https://bugzilla.mozilla.org/show_bug.cgi?id=1123055 ""Darken Colors" accessibility preference is not respected" OK, enough of accessibility evangelizing for today :-)
Boris, also see bug 1154402
I removed tracking-fennec from this bug and marked it as WONTFIX because I think what we need instead is smaller bugs and patches to fix specific issues. We currently do not have the time or resources to do a complete design specification for accessibility. But, I think we know in which areas we need improvements. So my suggestion is to simply keep filing smaller concrete feature/improvement bugs so that we go towards a better state of accessibility.
Please followup here if you think this is not the right approach or if you have alternative suggestions.