Hi Bryen, > > > > > > General Usage: > > > > > > My main challenge when using a computer these days is getting good high > > > contrast inversion along with larger fonts and windows. Generally, I > > > set my fonts on the system to about 16. > > > > You can still set this value using the tweak tools. > > > > Yes, and I currently do that. > > > > > > > That first step of getting to HighContrastInverse is probably the most > > > challenging because I have to first encounter a white window in > > > gnome-tweak-tool before I can finally find my way to the specific > > > setting under the right tab. Once that is accomplished, (through much > > > eye-squinting) the rest is "accessibly-easy" to do. > > > > > > However, now... with the introduction of GNOME 3.6, that theme is no > > > longer provided. > > As you mentioned this also on your original mail. In short: Yes, we know > > that the HightContrastInverse was dropped. > > > > Long explanation: we found that maintaining HightContrast and > > HightContrastInverse themes was a time-consuming task, and in several > > cases both were below the required maintenance status. More or less at > > the same time, Joseph was working on the inverse and color effects of > > the magnification tool, and we found that were really good. So we > > concluded that instead of having two half-made themes, it would be > > better to have a well done HighContrast theme, and that we could get the > > HightContrastInverse theme by just using HightContrast theme plus the > > inverse effect of the magnifier. > > > > Were we wrong with that conclusion/decision? > > > > I'm not going to dive off the plank and say "you were wrong!" :-) > Resources are what resources are. And we can scream bloody murder for > the loss of a feature all we want, but simply put, if the resource isn't > there to maintain it, we're up against a wall all around. > > But, from where I'm standing (or sitting!), the loss of > HighContrastInverse is quite painful. And I know this would affect just > about every person afflicted with Usher Syndrome. I've pointed out in > this thread what were my personal gains and losses were with 3.6, and > frankly, the baby was thrown out with the bathwater. I do not think we > should have gone with a "one or the other solution." > I would definitely encourage you to file a bug against Gnome-Themes-Standard explaining what solution would work best for your use case. The Design Team specifically mentioned that they would like feedback on this decision so users' needs can be met.
Thanks, Meg Ford > > The VM scenario is a perfect example where this wasn't a positive move > forward. At least you and I, and I'm sure many others, use VMs. > Inversed magnification instead of the traditional standbys, plus > performance problems, basically rendered ability to use VMs comfortably > useless. Let's face it, Linux users, regardless of whether you are > fully-sighted or fully-blind, are geeky users. The loss of VM usage is > too great here, especially for those of us who may have job-related > necessity to use VMs. > > > > > > > The mouse pointer is the next biggest challenge as it is often far too > > > small for me to see in shipped default. With the introduction of GNOME > > > 3, I no longer had the ability to scale my mouse. Instead, I would > > > search on the web to find large-sized pointers and manually add them to > > > my installation. > > > > Yes, on that ONCE presentation that I mentioned, they needed to do > > manual configuration like that for those students. > > > > And that's not good for the home user who doesn't have an IT staff > nearby to do the configurations and isn't familiar enough to know where > to go. > > > > > > > > > Naturally, I need to remember exactly where I'm supposed to put themes > > > or pointers in my filesystem and because this is a one-time thing to do > > > with each installation, I find myself scatching my head for a few > > > minutes to recollect the steps I was supposed to do with each new > > > release. Clearly, this wouldn't be a good process for less-experienced > > > GNOME users. > > > > Yes, in general, taking into account the summary of your experience, and > > the experience from other users, sometimes it is hard to know how to > > configure your desktop. We have a lack of documentation and user > > tutorials. The fact that some of the options are already considered as > > "common" on the universal settings and other as "custom" on the tweak > > tools, made the need of tutorials more important. In the same way, in > > several cases, that split is debatable, and some of the things available > > on the tweak tools should be available on the universal settings dialog > > (IMHO). > > > > Agreed. In some cases, we need better documentation. In other cases, > we need things to be more intuitive. Thus why I was proposing a > walkthrough observation. > > I think I basically did give my own personal walkthrough observation > here. But I will never assume that my issues are the same across the > board with other low-vision users. Low vision is like a snowflake, no > two are alike. (Hmm... does it snow in Spain rather than rain mainly on > the plain?) > > > > > > > > I like that High Contrast is now an option listed under the > > > Accessibility Icon. However, I'm disappointed HighContrastInverse > isn't > > > also an option. Having this option + a hotkey combination to > > > automatically enable this upon first setup would be awesome and remove > > > much of my initial machine setup challenges. If this could be done > > > without affecting the GNOME activity bar and notification alerts, it > > > would be super-awesome. > > > > Design team is working on the definition of the default > KeyboardShortcuts: > > https://live.gnome.org/GnomeOS/Design/Whiteboards/KeyboardShortcuts > > > > Probably it would be good to propose some kind of keyboard shortcut for > > this kind of theme activation. > > > Would be a great proposal once such inversion (whether through theme or > some other solution) exists. However, I think the user observation is > more important than going to the design team and telling them to create > a shortcut for a specific function. Once we understand more what the > typical user experience is when setting up a new machine, we can propose > a saner list of desired shortcuts where in some cases the same shortcut > could be used for multiple functions (by toggling through several > options.) > > Perhaps even an additional feature for toggling. For example, let's say > there's four options you can toggle through with a keyboard shortcut. > For each option you arrive at, a sound occurs. Thus you know you just > went to the next option. No this doesn't work well for DeafBlind > people, but we can't have everything! :-) > > That sound alert would be useful for people who don't know if they've > arrived at next option or if their machine is being too slow. > > > > > > > I would very much like to see us re-assess how low-vision users, who do > > > not rely on magnification as a whole, configure their machines and see > > > how we can make the steps shorter and more intuitive. > > > > As far as I understand this paragraph, you are suggesting to allow the > > configuration of the color effects outside of the magnification tool, > > right? We already have a bug related with that, although we still don't > > have any conclusion yet: > > https://bugzilla.gnome.org/show_bug.cgi?id=676814 > > > > > > > > For me, the ultimate solution in an ideal world would be not to even > > > create a workable Inverse theme, but to literally toggle screen > > > inversion in the workarea space of GNOME. But the theme option has > been > > > a reasonable fall-back in lieu of this toggle option. > > > > > But you already mentioned that just using the inverse effect made you > > hard to see the top panel and the alt+f2 run dialog. Could you elaborate > > that? > > By "workarea" I mean the area outside of the GNOME Shell elements > (activity bar, notification alerts, etc.) If toggling inversion could > be done without touching these elements (or treating these elements with > separate configuration) were possible, that would be my ideal solution. > > > > > Finally, thanks for your detailed report. It included a lot of things to > > think about, and pointed some elements that still require some work. > > > > And thank you for the patience to read through the long evaluation > email. :-) I hope it is viewed as a positive criticism rather than a > harsh bashing, which would never be my intention. > > I would love to get involved in these kinds of use-case discussions on a > more organized and pre-release basis. However, I find it difficult to > become a tester on a pre-released version because by nature they can be > quite buggy and by the time they are stable enough, feature freeze is > already introduced. By the time we are able to comment on successes and > failings, it is too late and any changes will have to wait until next > release 6 months later. Furthermore, the problem is exacerbated by what > I mention here about ability to test and provide feedback. So, by the > time we can comment on a certain implementation, we've already > encountered a new feature freeze and thus cannot expect a more perfect > implementation until the _NEXT_ release. Thus, in theory, it could take > a year (or possibly longer) to finally arrive at solutions that are > universally acceptable. > > How can we break this cycle to get us more directly involved during the > most critical moments? I am sure we are missing the opportunity to get > more timely feedbacks because many are in the same boat as me. > > > > Best regards > > > > > _______________________________________________ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list >
_______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
