E-mail List Archives
Thread: WCAG 2and high contrast
Number of posts in this thread: 13 (In chronological order)
From: Roger Hudson
Date: Sun, Oct 04 2015 6:42PM
Subject: WCAG 2and high contrast
No previous message | Next message →
Hi
I am in a bit of a quandary about the need to ensure images/icons still meet
WCAG 2 when viewed in high contrast, and would love to get the opinion of
some other list members.
Assume an important icon is an image or background image and there is a
non-visible text alternative that can be readout by screen readers. When the
page is viewed using a standard Windows display, the icon is clearly
visible. However, when Windows is used to change the display to high
contrast the inline image and the background image disappears.
My question is; would the disappearance of the image be a failure to comply
with SC 1.4.3 Colour contrast, or any other WCAG 2 Success Criteria?
Interestingly, this does not appear to happen with Macs. The iOS high
contrast doesn't seem to affect background images.
Thanks,
Roger
Roger Hudson
Web Usability
Mobile: 0405 320 014
Phone: 02 9568 1535
Web: www.usability.com.au
Blog: www.dingoaccess.com
Twitter: http://twitter.com/rogerhudson
Email: = EMAIL ADDRESS REMOVED =
From: Jonathan Avila
Date: Sun, Oct 04 2015 7:40PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
Roger, currently this is indicated as a failure of SC 1.1.1 via F3 Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information<http://www.w3.org/TR/WCAG20-TECHS/F3.html>;
The test procedure includes the following:
· If an image does convey important information, the information is provided to assistive technologies and is also available when the CSS image is not displayed.
I believe there is some discussion that other CSS techniques such as CSS content images via pseudo classes like before and after would meet the requirement. This is currently being discussed in the WCAG working group â if you have comments you may want to share them with the working group.
Instructions for Commenting on WCAG 2.0 Documents<http://www.w3.org/WAI/WCAG20/comments/>;
Best Regards,
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Roger Hudson
Date: Sun, Oct 04 2015 8:58PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
Thanks Jonathan,
But what about if it is an inline image with an alt attribute that is read out by screen readers - however in high contrast the image is either invisible or the resulting ratio between image and background is so low that it is effectively invisible?
From: _mallory
Date: Sun, Oct 04 2015 11:43PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
On Mon, Oct 05, 2015 at 01:58:15PM +1100, Roger Hudson wrote:
> Thanks Jonathan,
>
> But what about if it is an inline image with an alt attribute that is read out by screen readers - however in high contrast the image is either invisible or the resulting ratio between image and background is so low that it is effectively invisible?
>
Wouldn't this make the now-invisible icon inaccessible to non-screen-
reader users?
The guidelines don't necessarily say anything about "what if only
1 type of AT will expose this" I don't think but you'd think that
would affect the criteria.
Esp with browsers all being weird about whether they'll visibly show
the alt text or not based on the width of the image?
BTW Steve Faulkner has been passing around a bit of Javascript that
detects Windows high contrast where, when detected, an <img> could
be replaced with one that does show in high-contrast (so also if you
were using a transparent <img> with a sprite as background-image so
you could have an alt attribute, you could swap trans.png with
a non-sprite, visible on high-contrast version).
_mallory
>
From: Jonathan Avila
Date: Mon, Oct 05 2015 7:45AM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
> the image is either invisible or the resulting ratio between image and background is so low that it is effectively invisible?
Currently the contrast criteria only applies to text and images of text. I agree that this is an issue though. Also of issue are icon fonts that prohibit the user from specifying their own font or else the icon fonts will turn into squares or something else unhelpful. Some assistive technology maybe ZoomText when combined with browsers like Firefox may even disable icon fonts within the user agent. These are all things that need to be reviewed. I have communicated some of these issues to the low vision task force of the WCAG WG which is currently in its beginning stages.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Paul J. Adam
Date: Mon, Oct 05 2015 3:35PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
Windows High Contrast mode should not hide any images that are part of focusable elements. Or if Win HCM does hide the image then it should display the accessible name of the element from the accessibility API.
I would say it's a bug in Windows High Contrast Mode if it hides a focusable element's image without displaying the accessible name of the element. No other high contrast modes hide background images, e.g. OS X/iOS high contrast modes and ZoomText Screen Magnifier don't do this.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Oct 4, 2015, at 7:42 PM, Roger Hudson < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi
>
>
>
> I am in a bit of a quandary about the need to ensure images/icons still meet
> WCAG 2 when viewed in high contrast, and would love to get the opinion of
> some other list members.
>
>
>
> Assume an important icon is an image or background image and there is a
> non-visible text alternative that can be readout by screen readers. When the
> page is viewed using a standard Windows display, the icon is clearly
> visible. However, when Windows is used to change the display to high
> contrast the inline image and the background image disappears.
>
>
>
> My question is; would the disappearance of the image be a failure to comply
> with SC 1.4.3 Colour contrast, or any other WCAG 2 Success Criteria?
>
>
>
> Interestingly, this does not appear to happen with Macs. The iOS high
> contrast doesn't seem to affect background images.
>
>
>
> Thanks,
>
>
>
> Roger
>
>
>
>
>
> Roger Hudson
>
> Web Usability
>
> Mobile: 0405 320 014
>
> Phone: 02 9568 1535
>
> Web: www.usability.com.au
>
> Blog: www.dingoaccess.com
>
> Twitter: http://twitter.com/rogerhudson
>
> Email: = EMAIL ADDRESS REMOVED =
>
>
>
>
>
> > > >
From: Kevin Prince
Date: Mon, Oct 05 2015 5:44PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
It's probably worth returning to the intent of the checkpoint too "The intent of this Success Criterion is to provide enough contrast between text and its background so that it can be read by people with moderately low vision (who do not use contrast-enhancing assistive technology)."
That would both clearly show that this isn't a violation of 1.4.3 and also point to Paul's discussion as to a bug in Windows.
As long as the information conveyed, or action carried out, by the missing icon is apparent elsewhere than you have multiple ways and can still return to Home or see that the site belongs to "Acme" whether their logo is there or not.
Kev
Access1in5
0212220638
039290692
Independent Accessibility and IT Consultancy.
> On 6/10/2015, at 10:35, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
> Windows High Contrast mode should not hide any images that are part of focusable elements. Or if Win HCM does hide the image then it should display the accessible name of the element from the accessibility API.
>
> I would say it's a bug in Windows High Contrast Mode if it hides a focusable element's image without displaying the accessible name of the element. No other high contrast modes hide background images, e.g. OS X/iOS high contrast modes and ZoomText Screen Magnifier don't do this.
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
>> On Oct 4, 2015, at 7:42 PM, Roger Hudson < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Hi
>>
>>
>>
>> I am in a bit of a quandary about the need to ensure images/icons still meet
>> WCAG 2 when viewed in high contrast, and would love to get the opinion of
>> some other list members.
>>
>>
>>
>> Assume an important icon is an image or background image and there is a
>> non-visible text alternative that can be readout by screen readers. When the
>> page is viewed using a standard Windows display, the icon is clearly
>> visible. However, when Windows is used to change the display to high
>> contrast the inline image and the background image disappears.
>>
>>
>>
>> My question is; would the disappearance of the image be a failure to comply
>> with SC 1.4.3 Colour contrast, or any other WCAG 2 Success Criteria?
>>
>>
>>
>> Interestingly, this does not appear to happen with Macs. The iOS high
>> contrast doesn't seem to affect background images.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Roger
>>
>>
>>
>>
>>
>> Roger Hudson
>>
>> Web Usability
>>
>> Mobile: 0405 320 014
>>
>> Phone: 02 9568 1535
>>
>> Web: www.usability.com.au
>>
>> Blog: www.dingoaccess.com
>>
>> Twitter: http://twitter.com/rogerhudson
>>
>> Email: = EMAIL ADDRESS REMOVED =
>>
>>
>>
>>
>>
>> >> >> >> >
> > > >
From: Jonathan Avila
Date: Mon, Oct 05 2015 7:09PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
> Windows High Contrast mode should not hide any images that are part of focusable elements. Or if Win HCM does hide the image then it should display the
I'd say that is easier said than done. Replacing the image with text may not fit into the space allocated and extending the space could have unforeseen consequences in pages that are not fluid. Keeping the background image goes against the whole idea -- background images should not convey meaning and they are often very problematic for low vision users -- how is the OS supposed to know if the author intended the image to be a decorative background image or a meaningful background image.
> I would say it's a bug in Windows High Contrast Mode if it hides a focusable element's image without displaying the accessible name of the element. No other high contrast modes hide background images, e.g. OS X/iOS high contrast modes and ZoomText Screen Magnifier don't do this.
Mac and iOS IMO don't have a true high contrast mode -- they have an invert colors mode -- and yuck it's not something I want to use unless I have no other option. Inverting colors changes inline images and makes the images very unpleasant and harder to visually decipher. The invert colors only really provides -- well one option -- the opposite of what was there -- that often but not always a single high contrast option. Windows high contrast mode on the other hand replaces foreground, background, and other control specific colors with user specified or pre-defined high contrast options. That is the Windows high contrast mode is customizable allowing the user to say what colors they want to see in high contrast -- perhaps that's black on white or green on white and inline images stay the way they were created -- except for the transparent parts. Users can specify colors for selection, borders, links, and all sorts of things in the OS.
So I disagree with those people who say Windows HC mode has a bug and should display background images -- background images -- are well background images and thus not content images and thus should be removed to assist users with low vision in reading page content. It really sounds like we need a CSS content image property that works and is supported and then developers can say this is a content image and this is a background image and then user agents can correctly hide or display the image per its purpose. Perhaps the current content and alt CSS properties are moving this direction.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Paul Adam
Date: Mon, Oct 05 2015 7:41PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
The accessible name could be in a keyboard accessible tooltip. Most
background images that are focusable are not decorative content,
they're UI controls so don't hide them. OS X has a high contrast mode
that is different than invert colors. I would rather Windows HCM not
hide background images on focusable elements than to try and convince
all web developers of the world to implement a specific hack for
WinHCM.
Sent from my iPhone
On Oct 5, 2015, at 8:09 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> Windows High Contrast mode should not hide any images that are part of focusable elements. Or if Win HCM does hide the image then it should display the
>
> I'd say that is easier said than done. Replacing the image with text may not fit into the space allocated and extending the space could have unforeseen consequences in pages that are not fluid. Keeping the background image goes against the whole idea -- background images should not convey meaning and they are often very problematic for low vision users -- how is the OS supposed to know if the author intended the image to be a decorative background image or a meaningful background image.
>
>> I would say it's a bug in Windows High Contrast Mode if it hides a focusable element's image without displaying the accessible name of the element. No other high contrast modes hide background images, e.g. OS X/iOS high contrast modes and ZoomText Screen Magnifier don't do this.
>
> Mac and iOS IMO don't have a true high contrast mode -- they have an invert colors mode -- and yuck it's not something I want to use unless I have no other option. Inverting colors changes inline images and makes the images very unpleasant and harder to visually decipher. The invert colors only really provides -- well one option -- the opposite of what was there -- that often but not always a single high contrast option. Windows high contrast mode on the other hand replaces foreground, background, and other control specific colors with user specified or pre-defined high contrast options. That is the Windows high contrast mode is customizable allowing the user to say what colors they want to see in high contrast -- perhaps that's black on white or green on white and inline images stay the way they were created -- except for the transparent parts. Users can specify colors for selection, borders, links, and all sorts of things in the OS.
>
> So I disagree with those people who say Windows HC mode has a bug and should display background images -- background images -- are well background images and thus not content images and thus should be removed to assist users with low vision in reading page content. It really sounds like we need a CSS content image property that works and is supported and then developers can say this is a content image and this is a background image and then user agents can correctly hide or display the image per its purpose. Perhaps the current content and alt CSS properties are moving this direction.
>
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>
From: Jonathan Avila
Date: Mon, Oct 05 2015 8:08PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
> The accessible name could be in a keyboard accessible tooltip.
In the situation where the image is not displayed but a keyboard and mouse accessible tooltip is present would require a user with low vision to either tab to or hover their mouse over blank areas of the page trying to figure out what elements are interactive. Only getting something on hover or focus isn't comparable access IMO.
> Most background images that are focusable are not decorative content, they're UI controls so don't hide them.
This is an intriguing idea but it isn't a given -- buttons with text can use background images as well -- I've seen this many times. Instead of using a hack -- authors should be able to more clearly state which ones are decorative and which are not.
> OS X has a high contrast mode that is different than invert colors.
The only settings I'm aware of are increase contrast, reduce transparency, and display contrast. I'm not aware of a setting allowing the user to choose colors. Increase contrast makes some small but helpful visual changes and reduce transparency is helpful. The display contras settings in my experience mostly makes things worse. In the settings dialog the slider seems to make the background whiter. Using the display contrast in many place such as the app > update screen slider seems to whiteout most things making most text less readable or even invisible in the standard display mode. What the display contrast slider is really good at is making the invert colors features work much better. Basically if you use invert colors and then the display contrast slider it produces better results -- but then again I don't want to use invert colors. The display contrast slider is a filter that lightens lighter colors -- which means if you have gray text it will make it lighter -- this is bad in standard display mode but good in inverse color mode.
In my experience most of these filters just don't work correctly across a broad spectrum of situations -- there are too many edge (or in this case I think middle) cases.
> I would rather Windows HCM not hide background images on focusable elements than to try and convince all web developers of the world to implement a specific hack for WinHCM.
You could make the same argument for just about anything -- why not have screen readers interpret the language so web developers don't need to set the language -- this is a valid argument I've seen in W3C lists. You could even say -- why have authors set the contrast of pages at all if the user can change the contrast?
We need to strike a balance between author and user agent settings.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Paul J. Adam
Date: Mon, Oct 05 2015 8:21PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
My argument is that the accessible name has already been provided by the author for the screen reader user so the WinHCM at should take advantage. I'm not saying AT should try to guess something like what the language is or what the form label is. Authors provide the info to A11y API and the AT should present it. I don't think authors should have to hack their way around very specific AT like Windows High Contrast mode.
Paul J. Adam
Accessibility Evangelist
www.deque.com
>
>
>> I would rather Windows HCM not hide background images on focusable elements than to try and convince all web developers of the world to implement a specific hack for WinHCM.
>
> You could make the same argument for just about anything -- why not have screen readers interpret the language so web developers don't need to set the language -- this is a valid argument I've seen in W3C lists. You could even say -- why have authors set the contrast of pages at all if the user can change the contrast?
From: Kevin Prince
Date: Mon, Oct 05 2015 8:34PM
Subject: Re: WCAG 2and high contrast
← Previous message | Next message →
Interpret the language of the page - that's ambitious. So schadenfreude will be easy enough I'm sure but what about all the other words borrowed and absorbed over the years. Probably pushed by a developer with a more consistent version of language - wouldn't work in New Zealand - kia ora.
K
K
Access1in5
0212220638
039290692
Independent Accessibility and IT Consultancy.
> On 6/10/2015, at 15:21, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
> My argument is that the accessible name has already been provided by the author for the screen reader user so the WinHCM at should take advantage. I'm not saying AT should try to guess something like what the language is or what the form label is. Authors provide the info to A11y API and the AT should present it. I don't think authors should have to hack their way around very specific AT like Windows High Contrast mode.
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>>
>>
>>> I would rather Windows HCM not hide background images on focusable elements than to try and convince all web developers of the world to implement a specific hack for WinHCM.
>>
>> You could make the same argument for just about anything -- why not have screen readers interpret the language so web developers don't need to set the language -- this is a valid argument I've seen in W3C lists. You could even say -- why have authors set the contrast of pages at all if the user can change the contrast?
> > > >
From: Birkir R. Gunnarsson
Date: Sun, Oct 11 2015 6:00PM
Subject: Re: WCAG 2and high contrast
← Previous message | No next message
What are people's thoughts on using a a CSS background image to
rpvodie info about a focusable element, also providing an off-screen
"alternative text".
<!--
- The PDF_Icon CSS class includes a PDF log or image displayed in the
background.
- The visuallyHidden class uses clip method to hide text off screen
but make it available to screen reder users.
-->
<button class="PDF-_icon">Download File
<span class="visuallyHidden">PDF</span>
</button>
While this works for a screen reader, it would not work for someone
who customized styl sheets (and I also believe that inverting color
mode hides the image, as previously discussed).
The very obvious answer is that, yes, it is a CSS image, it has
information, and that would violate SC 1.1.1.
Use an inline image with appropriate alt tag instead.
But often webpages are turning to this technique to avoid loading
multiple inline images.
What if we made use of to the title attribute here
<button class="PDF-_icon" title="PDF">Download File</button>
I guess the CSS content attribute may solve this, though the
definition of CSS (use for presentation) is getting increasingly
inaccurate.
On 10/5/15, Kevin Prince < = EMAIL ADDRESS REMOVED = > wrote:
> Interpret the language of the page - that's ambitious. So schadenfreude will
> be easy enough I'm sure but what about all the other words borrowed and
> absorbed over the years. Probably pushed by a developer with a more
> consistent version of language - wouldn't work in New Zealand - kia ora.
> K
>
> K
> Access1in5
> 0212220638
> 039290692
> Independent Accessibility and IT Consultancy.
>
>
>
>> On 6/10/2015, at 15:21, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> My argument is that the accessible name has already been provided by the
>> author for the screen reader user so the WinHCM at should take advantage.
>> I'm not saying AT should try to guess something like what the language is
>> or what the form label is. Authors provide the info to A11y API and the AT
>> should present it. I don't think authors should have to hack their way
>> around very specific AT like Windows High Contrast mode.
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>>
>>>
>>>> I would rather Windows HCM not hide background images on focusable
>>>> elements than to try and convince all web developers of the world to
>>>> implement a specific hack for WinHCM.
>>>
>>> You could make the same argument for just about anything -- why not have
>>> screen readers interpret the language so web developers don't need to set
>>> the language -- this is a valid argument I've seen in W3C lists. You
>>> could even say -- why have authors set the contrast of pages at all if
>>> the user can change the contrast?
>> >> >> >> >
> > > > >
--
Work hard. Have fun. Make history.