This is a serious accessibility bug (when using Writer on Windows) for folk with visual impairments who use a Windows High-Contrast Colour theme and need specific background and text colours to read comfortably. It looks as if this bug was introduced in LibreOffice 4.1. It definitely doesn't occur with LibreOffice 3.5.

Potential duplicate of bug 64842.
Adding bdrung and bjoern.michaelsen to CC list as this patch is a potential culprit https://gerrit.libreoffice.org/#/c/238/ (sorry for misinterpretation if any).
Please evaluate and comment. Thanks.

> Potential duplicate of bug 64842.
Yes, this does look like a potential duplicate. But since bug 64842 was filed against Ubuntu and not Windows, I wouldn't be sure that the fix for that one would fix the similar problem on windows. The offending code for each OS may be slightly different.

I've read the comment for change Ia42ca7882f0d2dd1f2a304db5e4b5aaba23244fc. This change introduces a serious accessibility flaw for folk with a vision disability. I can no longer use later versions of LibreOffice because of this. As a developer myself, I would have said that a better fix for the problem would have been to correctly detect when Open Office / LibreOffice has been set to work in accessibility mode and when so, for the displayed document colours to inherit from the underlying high-contrast theme accordingly. When LibreOffice is not in set in accessibility mode, then by all means default to other more appropriate display colours for the document.

It appears the developer of the patch may misunderstand why (at least in Windows) the High-Contrast themes exist and how visually impaired people like myself benefit from them.

Various partially sighted or blind people and folk with other visual impairments benefit from a custom text foreground and page background colours. Setting the host OS to a high-contrast accessibility theme should trigger all applications to inherit that theme. There are of course some offending applications in Windows that don't this, but most do. Open Office / LibreOffice has been particularly good at this in the past - and has been especially useful to people with a vision disability with it's ability to adapt to document display colours accordingly when accessibility is set to on (this is now broken). This has been singly the biggest winning feature for which why I choose OpenOffice/LibreOffice over Word.

I suffer from a light sensitivity disorder called Visual Stress for which white / light backgrounds on paper and computer screens cause considerable discomfort and migraines. This disorder affects 15 - 20 percent of the population at varied levels of severity from very mild to extreme. Is is also known as Meares-Irlen Syndrome or just Irlen Syndrome. Colour is of extreme importance for these people to be able to see and read comfortably. We rely on high-contrast OS themes to get around the problem to some extent. White background documents and UIs cause these people a multitude of debilitating symptoms including migraines, not being able to think straight, loss of some co-ordination, irritability, nausea and quite a few others - different for each individual.

Please honour high-contrast themes in Windows. They are there for a reason.

In sort, please restore LibreOffice's ability to adhere a document's displayed colours to the underlying high-contrast theme, when the applicable accessibility settings have been set in the application's preferences.

Actually, the bug occurs when I load the context help module package to 
work with the software.

I uninstalled the HELP stuff by doing a System Restore and got my 
Windows Aero feature back. I am able to use the software suite with no 
problem.

Elmer

On 11/25/2013 11:40 AM, bugzilla-daemon@freedesktop.org wrote:
>
> *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=71511#c3> 
> on bug 71511 <https://bugs.freedesktop.org/show_bug.cgi?id=71511> from 
> nicciglen@hotmail.com <mailto:nicciglen@hotmail.com> *
> > Potential duplicate ofbug 64842  <show_bug.cgi?id=64842>.
> Yes, this does look like a potential duplicate. But sincebug 64842  <show_bug.cgi?id=64842>  was filed
> against Ubuntu and not Windows, I wouldn't be sure that the fix for that one
> would fix the similar problem on windows. The offending code for each OS may be
> slightly different.
>
> I've read the comment for change Ia42ca7882f0d2dd1f2a304db5e4b5aaba23244fc.
> This change introduces a serious accessibility flaw for folk with a vision
> disability. I can no longer use later versions of LibreOffice because of this.
> As a developer myself, I would have said that a better fix for the problem
> would have been to correctly detect when Open Office / LibreOffice has been set
> to work in accessibility mode and when so, for the displayed document colours
> to inherit from the underlying high-contrast theme accordingly. When
> LibreOffice is not in set in accessibility mode, then by all means default to
> other more appropriate display colours for the document.
>
> It appears the developer of the patch may misunderstand why (at least in
> Windows) the High-Contrast themes exist and how visually impaired people like
> myself benefit from them.
>
> Various partially sighted or blind people and folk with other visual
> impairments benefit from a custom text foreground and page background colours.
> Setting the host OS to a high-contrast accessibility theme should trigger all
> applications to inherit that theme. There are of course some offending
> applications in Windows that don't this, but most do. Open Office / LibreOffice
> has been particularly good at this in the past - and has been especially useful
> to people with a vision disability with it's ability to adapt to document
> display colours accordingly when accessibility is set to on (this is now
> broken). This has been singly the biggest winning feature for which why I
> choose OpenOffice/LibreOffice over Word.
>
> I suffer from a light sensitivity disorder called Visual Stress for which white
> / light backgrounds on paper and computer screens cause considerable discomfort
> and migraines. This disorder affects 15 - 20 percent of the population at
> varied levels of severity from very mild to extreme. Is is also known as
> Meares-Irlen Syndrome or just Irlen Syndrome. Colour is of extreme importance
> for these people to be able to see and read comfortably. We rely on
> high-contrast OS themes to get around the problem to some extent. White
> background documents and UIs cause these people a multitude of debilitating
> symptoms including migraines, not being able to think straight, loss of some
> co-ordination, irritability, nausea and quite a few others - different for each
> individual.
>
> Please honour high-contrast themes in Windows. They are there for a reason.
>
> In sort, please restore LibreOffice's ability to adhere a document's displayed
> colours to the underlying high-contrast theme, when the applicable
> accessibility settings have been set in the application's preferences.
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You are on the CC list for the bug.
>

@nicciglen@hotmail.com: did you posted about this on Accessibility, UX-Advise or  Dev lists (http://nabble.documentfoundation.org/LibreOffice-f1639495.html)? I have to admit that this bug is the first place where I've read about Visual Stress or Meares-Irlen Syndrome and surely will link to it every time someone will file a bug about changing default UI color settings.

Also adding michael.meeks@collabora.com to CC list who contributed a patch in this area (http://cgit.freedesktop.org/libreoffice/core/commit/?id=0acdeacbe774b7e05323ad80b556e7102a083192) asking for evaluation and comment.

@bfoman: Thanks for the heads up on those mailing lists. I wasn't aware of the UX-Advice and Accessibility mailing lists. I will most likely post to them in due course. UI developers need to be aware of these accessibility issues for visually impaired users.

Default UI colours are fine, as long as two things are taken into consideration.

1. Enabling overriding UI colours with the underlying Accessibility theme of the host operating system, if one is active. LibreOffice has done this well in the past. Now it is broken in this respect.

2. Enabling visually impaired users to customise to UI look and colours as much as possible. In the specific case of visual stress/irlen syndrome, being able to customise colours (especially background and text colours) to precise RGB values is very important.

Hard coding a white background in a UI is one of the worst things a UI developer can do for those with Visual Stress.

The change from [1] may caused this bug. To quote the reason for this change: "The font and document color of a Writer document or an Impress presentation
should not be derived from a desktop theme. A Writer documents needs to look
good on paper. An Impress presentation may have it's own theme. The appearance
of a document should not change by changing the desktop theme."

The accessibility options should allow violating the rule stated above. It should be possible to override the document/presentation colors by the hight-contrast color schema.

[1] https://gerrit.libreoffice.org/#/c/238/

To add to Benjamin Drung's previous comment: The LibreOffice Options under LibreOffice / Accessibility are there for a reason. Up until relatively recently the behaviour of Writer (when these options are set) was to detect under Windows (at least) when a high-contrast OS accessibility colour scheme was being used and then override the displayed document colours accordingly. Please restore this important functionality to help people with visual impairments use LibreOffice.

Does anyone know When is this important accessibility bug going to be fixed? If I was a C++ developer myself I would help out and fix it, but alas I am not.

To understand why this kind of thing is important please look at the EU Mandate 376 at <http://www.mandate376.eu/> regarding regulations and standards in the EU covering ICT Accessibility requirements.
See the standard EN 301 549 "Accessibility requirements for public procurement of ICT products and services in Europe" at <http://bit.ly/1idBi9Z>

Adding Robinson Tryon from QA team who can escalate this as CCed developers did not comment the issue.

(In reply to comment #8)
> To add to Benjamin Drung's previous comment: The LibreOffice Options under
> LibreOffice / Accessibility are there for a reason. Up until relatively
> recently the behaviour of Writer (when these options are set) was to detect
> under Windows (at least) when a high-contrast OS accessibility colour scheme
> was being used and then override the displayed document colours accordingly.
> Please restore this important functionality to help people with visual
> impairments use LibreOffice.

Question: When did the behavior change?

We could try bibisecting on GNU/Linux, but only if the high-contrast theme detection worked there as well. Nicciglen -- Do you know?

---

Sounds like general agreement on this problem, so Status -> NEW
Whiteboard: a11y BibisectRequest

So yes, this is likely caused by https://gerrit.libreoffice.org/#/c/238/. We could:
1/ simply revert that and have LibreOffice behave as needed for accessibility
2/ keep that and only behave as needed for accessibility when "automatically detect high contract mode of operating system" is checked in the options.


For 2/, here is a an example of how to read that value: http://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx#636

Im not convinced that that is the right way to go: We are mixing two usecases here: a/ accessibility and b/ people using a dark desktop theme without a need for accessibility.

Ultimately, IMHO what we really need is a dark theme no-accessibility theme, so that we can keep these too apart.

(In reply to comment #11)
> 2/ keep that and only behave as needed for accessibility when "automatically
> detect high contract mode of operating system" is checked in the options.
> ... 
> Im not convinced that that is the right way to go: We are mixing two
> usecases here: a/ accessibility and b/ people using a dark desktop theme
> without a need for accessibility.

Agreed. I'm not sure we can automatically determine correct LibreOffice behavior based on the colors of the desktop theme.

> 
> Ultimately, IMHO what we really need is a dark theme no-accessibility theme,
> so that we can keep these too apart.

I'm not sure what you mean. The simplest solution in my mind would be to have an (accessibility) option "Use/inherit colors from desktop theme".

Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b0e8b9c8541250be65ce228b67ff5adb105b732

fdo#71511: in autodetected a11y HC mode, pull background color from theme



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Commit backported to -4-2 as:

 https://gerrit.libreoffice.org/#/c/7484/

and waiting for review. Note that this needs a LibreOffice restart after changing "Tools->Options->A11y->automatically detect high contract mode of operating system" to take effect.

> in autodetected a11y HC mode, pull background color from theme

Thanks for looking into fixing this bug.

HOWEVER please NOTE: When a11y HC mode is detected, *both* the text colour and background colour need to be pulled from underlying OS theme.

> - dark theme default to high contrast
>  - as per fdo#35365, having a dark document background is 
>        inconvenient for non-a11y endusers
>  - a11y standard require the (rather ugly) background for a11y
>  - thus, when "automatically detect high contract mode of operating system" in >   Tools->Options->a11y is enabled, use the dark document background by
>       default, otherwise use a white default 

From the code commit comment, I'm not sure if the requirements for this a11y feature have been fully understood.

A high-contrast theme - doesn't necessarily need to have a dark background. It can have any background colour or text colour combination that a partially sighted user finds easier to see. It could be say bright orange background with black text.

The point is that Windows (and I'm sure Linux) can have several high-contrast themes, where the background colour can be anything and the foreground colour can be anything that is beneficial for the partially sighted user.

In summary, as long as you are pulling *both* the background and foreground colours from the OS a11y theme, when an OS high-contrast theme is detected - then you are restoring the functionality that LibreOffice / Open Office have had for a very long time. 

(PS. Yes, high-contrast themes may look ugly to non-a11y users, but they are a life-changing enabler for people with various vision problems)

@Qubit

> Question: When did the behavior change?

I can't pinpoint exactly, but in my original bug description I noted the version where the problem occurs, and a previous version where the problem doesn't occur. So it was introduced (on Windows) somewhere after v3.5.5.3 up to and including 4.0.

> We could try bibisecting on GNU/Linux, 
> but only if the high-contrast theme detection worked
> there as well. Nicciglen -- Do you know?

Sorry, I haven't tried LibreOffice on Linux for quite a long time.

Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f7a0275be241b8a5e1d1cda0a1da613e3af61d3

fdo#71511: reload ColorConfig after tweaking relevant a11y settings



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

this one was a regression by fdo#35365 introduced with 4.0/3.6.6 affecting all platforms on all archs and is fixed now on master.

@nicciglen: Dont featurecreep this bug, this one is about the background colors regression, for everything else please file a new, well-scoped bug (see LibreOffice bug handling guidelines).

All right already!!

I got the message 30 f*&king times!

Take me off the damn Cc list.


On 1/16/2014 2:12 PM, bugzilla-daemon@freedesktop.org wrote:
> V Stuart Foote <mailto:vstuart.foote@utsa.edu> changed bug 71511 
> <https://bugs.freedesktop.org/show_bug.cgi?id=71511>
> What 	Removed 	Added
> See Also 		https://bugs.freedesktop.org/show_bug.cgi?id=64842
>
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You are on the CC list for the bug.
>

@Bjoern,
(In reply to comment #18)
> this one was a regression by fdo#35365 introduced with 4.0/3.6.6 affecting
> all platforms on all archs and is fixed now on master.

Thanks for the heads up in http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f7a0275be241b8a5e1d1cda0a1da613e3af61d3 about the icons being hard set. I'd toggled the setting recently following a Accessibility ML session, and couldn't revert. It is simplest to clear per-user profile to get back to default icons.

> 
> @nicciglen: Dont featurecreep this bug, this one is about the background
> colors regression, for everything else please file a new, well-scoped bug
> (see LibreOffice bug handling guidelines).

Not so sure it is creep. As @nicciglen mentioned in the OP, for A11Y the requirement is for high contrast (HC) between background and foreground. So with background settings no longer automatic--if the foreground color 'automatic' selection happens to pick a low contrast color pair, the document will be unreadable by those needing HC asssitive technology.

Best case would be pick up both OS background and foreground colors as set by OS in HC mode. But at a minimum would need to set a HC foreground color complementary to what ever background color is being set. Can the background color algorithm be adjusted to select a complementary foreground color?

Verifying fixed on Windows 7 sp1, 64-bit with todays TB 39 build of master
Version: 4.3.0.0.alpha0+
Build ID: 12ca5ec6f4485ab8c837d32eefdf39a2dda025a4
TinderBox: Win-x86@39, Branch:master, Time: 2014-01-17_02:58:58

With the Tools -> Options -> Accessibility: Options for high contrast appearance checked on.

The background and foreground font colors are following the system HC modes set from Windows 7 Ease of Access Center. Tested the High Contrast#1, High Contrast #2, and High Contrast White color offerings. LibreOffice color selections matched all well.

However, as noted...when toggling HC mode off the LO component icon sets do not revert to non-HC defaults as was commented.

=-=-=

Verifying fixed on Centos 6.4, 64-bit with todays TB 46 build of master
Version: 4.3.0.0.alpha0+
Build ID: 12ca5ec6f4485ab8c837d32eefdf39a2dda025a4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-01-17_02:58:10

With the Tools -> Options -> Accessibility: Options for high contrast appearance all checked on.

Both the High Contrast, and High Contrast Inverse OS themes both were picked up in LibreOffice. 

A bit limited, so increased contrast could be obtained changing the Tools -> Options -> Appearance: Custom colors -- Font color.

And, when toggling back to default System theme, component icons also do not revert to non-HC defaults.

*** Bug 64842 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> @Bjoern,
> Best case would be pick up both OS background and foreground colors as set
> by OS in HC mode. But at a minimum would need to set a HC foreground color
> complementary to what ever background color is being set. Can the background
> color algorithm be adjusted to select a complementary foreground color?

AFAICS this is what is done now, as we are not only getting the background (DO_COLOR), but also the foreground (FONTCOLOR) from the theme (see commit diff).

Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=23221e48495262d0384c9169a0d8a01db8a5dab5&h=libreoffice-4-2

fdo#71511: in autodetected a11y HC mode, pull background color from theme


It will be available in LibreOffice 4.2.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.