Re: aria label on a div alternative text for background images.

Hi, David.

> I'm hearing you say, some low vision users will be turning off their 
> CSS, or changing it, and therefore any CSS images that convey meaning 
> will be lost unless there is a visual text replacement.

High contrast mode turns CSS background off to ensure that any text that 
has changed its colour to the "high contrast" foreground color is not 
over any -previously visible- CSS background image. This is the typical 
(and I must say "desirable") behaviour of high-contrast mode on Windows.

High contrast mode is a very common "assistive technology" for low 
vision users with retinal diseases such as retinitis pigmentosa and 
others related to photoreceptors death (especially rods). This retinal 
diseases usually cause a great degradation in contrast perception and 
also dazzling effects due to bright backgrounds, so many users tend to 
prefer dark backgrounds with light foregrounds. Other diseases cause 
damage in the cones, and these users might prefer light backgrounds with 
dark foregrounds. In any case, any high-contrast mode disable 
backgrounds to prevent text-over-wrong-background issues.


> I'm hearing Ramon say that further to that, even CSS background images
 > that are decorative mess up colour foreground/background adjustments.
 > Do I have that right Ramon?

No, not really. Purely decorative backgrounds can safely disappear 
without impact on accessibility. It would sometimes be preferable to 
show a border or outline that gives a clue of the bounding box, but this 
is more a "strong preference" than a requirement.

However, it can happen that someone creates a "background" that is not a 
CSS background, that is, a layer with an <img> that is under another 
layer with the text. In these cases, high contrast mode will not hide 
the <img>, and therefore it can happen that the text is unreadable (for 
example, if the text is changed to "white" and the <img> has a big white 
area).


> We currently don't have an explicit failure for providing CSS background 
> images for content if there is a text alternative, would either of you 
> like to propose a failure.

I'm not sure that we could add a failure to WCAG, because this is an 
issue that only affects Windows users. Therefore, it could happen that 
the context of use of the web page is a non-Windows closed environment 
and the issue does not occur (there are other similar issues with custom 
stylesheets, but I think they cannot be considered "common AT").

Anyway, my opinion is that any Sufficient Technique / Failure should 
always contain an "Accessibility Support" section, so we could then add 
a failure of CR #4 for CSS backgrounds that would only apply when 
Windows -and high contrast mode- is considered in the evaluation.

Note: currently, the Working Draft of WCAG-EM establishes a Step to 
"Define an Accessibility Support Baseline". If this baseline includes 
Windows OS I would probably consider also high contrast modes due to its 
prevalence among low vision users.


> I'm having a hard time mapping it to any current failure.
> I'd say we haven't done much in WCAG 2 to ensure flexibility
 > with colours. There is only one failure I know of.

Well, this is more "philosophycal"... There are many WCAG SC aimed at 
screen reader users, but not many at users of low vision tools. For 
example, contrast ratio may be ok in "normal mode" but insufficient when 
we invert colors, and high contrast mode creates the above issues (and 
others). There are also other readability issues such as being able to 
select typography, justification, colors and so on, and SC 1.4.4 is 
sadly interpreted as "Control +" is enough (ignoring that many low 
vision users navigate using "Zoom text only"). Focus indicator, icons or 
form controls do not require contrast, labels can be far from their 
controls (problematic when using magnification) and so on.

Maybe some of these things could be clarified or added in a WCAG 3.0 
spec, some others are not feasible due to their possible implications on 
design.

For the moment we -at ONCE Foundation- usually inform about HC issues in 
SC 1.1.1 (no alternative -for HC users-) or SC 1.4.3 (contrast -for HC 
users-), indicating that these issues arise due to a lack of 
accessibility support in the "accessibility support baseline" that we 
define. Please understand that ONCE is an organisation aimed at ensuring 
accessibility for blind AND low vision users, so we always tend to 
include tools that we know our affiliates use.


In any case, we are conscious that this is something beyond current 
requirements of WCAG in most cases, unless you consider high contrast 
mode as part of your baseline environment. Due to the nature of ONCE, we 
do this in our methodology for the Technosite certification label, which 
also goes a bit beyond WCAG 2.0 in other aspects. I'm not saying that 
everyone should do the same, but obviously I am not happy any technique 
that suggests ways to provide alternatives that would go against high 
contrast users.

Cheers,
Ramón.

Received on Monday, 26 May 2014 23:54:54 UTC