Re: High Contrast support with Browsers.

The high contrast is a serious problem. More generally the access to color
framework is just as important. The problem hinges on how we permit and
test color access.

Our policies also leave people who need low brightness out. The terminal
dimming only goes so far if the basic colors are problematic to the reader.
This is a documented user need that was identified by the LVTF Requirements
document.

We could not solve it this time around, but it needs solving. I think we
need to do some baseline testing.

Wayne

On Wed, May 30, 2018 at 6:13 AM, Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> On Windows there is a flag for high contrast (*SPI_GETHIGHCONTRAST)*
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> dd318443(v=vs.85).aspx
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> *Level Access*
>
> jon.avila@levelaccess.com
>
> 703.637.8957 office
>
>
>
> Visit us online:
>
> Website <http://www.levelaccess.com/> | Twitter
> <https://twitter.com/LevelAccessA11y> | Facebook
> <https://www.facebook.com/LevelAccessA11y/> | LinkedIn
> <https://www.linkedin.com/company/level-access> | Blog
> <http://www.levelaccess.com/blog/>
>
>
>
> *Looking to boost your accessibility knowledge? Check out our free
> webinars!* <https://www.levelaccess.com/compliance-resources/webinars/>
>
>
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>
>
> *From:* Ian Sharpe <themanxsharpy@gmail.com>
> *Sent:* Thursday, May 10, 2018 6:35 AM
> *To:* Jonathan Avila <jon.avila@levelaccess.com>; WAI Interest Group <
> w3c-wai-ig@w3.org>
> *Subject:* RE: High Contrast support with Browsers.
>
>
>
> From an accessibility perspective, I feel all apps, including the browser,
> should respect native OS settings / colour scheme etc. However, I’m not
> sure it makes sense for apps to respect the native OS theme in all cases,
> as many people may use a different colour scheme for any number of
> reasons,  including personal preference. I think these users would actually
> be more surprised / confused if they went to a site of a well-known brand
> and the site was displayed using their native OS theme instead of the usual
> branding for example? I’m not sure marketing types who spend a lot of money
> on website branding / colour schemes would be particularly happy either?
>
>
>
> That said, for me at least on Windows 10 using the inverted high-contrast
> theme, both Firefox and Edge respect the native colour scheme, but Chrome
> doesn’t, so it would seem there is some ambiguity around this issue?
>
>
>
> I guess the obvious next question then is how is the browser expected to *
> *know** when a user is using a high-contrast or custom theme for
> accessibility reasons across all possible platforms?
>
>
>
> May be FF and Edge are making assumptions on the basis that I am using a
> high-contrast theme (set via ease of access settings), or because I’m using
> a screen reader or have other accessibility settings enabled, which for my
> particular use case is great as I didn’t have to do anything to get my
> desired behaviour, and I would prefer it if Chrome adopted the same
> approach as well. But I’m not sure how feasible this approach might be for
> all platforms? Indeed, what about the case when a user creates a custom
> theme for accessibility reasons but makes no other accomodations?
>
>
>
> Based on the above, here’s my proposed logic:
>
>
>
> If an app can determine whether the OS has been customized for
> accessibility reasons, the app (including browsers) should respect these
> settings by default, so that the user is not required to do anything
> themselves.
>
>
>
> If the app isn’t able to make this assumption, the app should do nothing
> by default, but should provide a switch to enable the user to change the
> behaviour of the app to respect native OS settings if required.
>
>
>
> Cheers
>
> Ian
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Jonathan Avila <jon.avila@levelaccess.com>
> *Sent: *09 May 2018 12:33
> *To: *WAI Interest Group <w3c-wai-ig@w3.org>
> *Subject: *Re: High Contrast support with Browsers.
>
>
>
> I would consider the need for high contrast applicable.   We do have some
> techniques to support it such as Failure F3 relates to background images
> when css images are not displayed.
>
>
>
> Jonathan
>
> Sent from my iPhone
>
>
> On May 8, 2018, at 10:23 PM, Sean Murphy (seanmmur) <seanmmur@cisco.com>
> wrote:
>
> All,
>
>
>
> General query in relation to high contrast with browsers. Should the
> browser honor the OS high contrast settings or should the CSS override the
> OS high contrast? My view is the browser should honor the OS high contrast
> settings. Not sure if this is the case now.
>
>
>
>
>
> Regards
>
> Sean Murphy
>
> Accessibility Software ENGINEER
>
> seanmmur@cisco.com
>
> Tel: +61 2 8446 7751
>
>
>
> Cisco Systems, Inc.
>
> The Forum 201 Pacific Highway
> <https://maps.google.com/?q=201+Pacific+Highway+%0D%0A+ST+LEONARDS+%0D%0A+2065+%0D%0A+Australia&entry=gmail&source=g>
>
> ST LEONARDS
> <https://maps.google.com/?q=201+Pacific+Highway+%0D%0A+ST+LEONARDS+%0D%0A+2065+%0D%0A+Australia&entry=gmail&source=g>
>
> 2065
> <https://maps.google.com/?q=201+Pacific+Highway+%0D%0A+ST+LEONARDS+%0D%0A+2065+%0D%0A+Australia&entry=gmail&source=g>
>
> Australia
> <https://maps.google.com/?q=201+Pacific+Highway+%0D%0A+ST+LEONARDS+%0D%0A+2065+%0D%0A+Australia&entry=gmail&source=g>
>
> cisco.com
>
>
>
> http://www.cisco.com/go/accessibility
>
>
>
> Think before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> http://www.cisco.com/c/en/us/about/legal/terms-sale-
> software-license-agreement/company-registration-information.html
>
>
>
>
>
>
>

Received on Tuesday, 5 June 2018 22:26:19 UTC