RE: Discussion of alt for CSS images

Jon (or others),
Do we have a test file with the different ways of including an image represented somewhere?  I’d love to be able to try this out and know how different UA’s handle the images.
AWK

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Thursday, March 26, 2015 2:00 PM
To: WCAG
Subject: RE: Discussion of alt for CSS images


Ø  Yes that is what I was referring to. I think this is a problem especially for low vision users - perhaps we have done a disservice to those users in this instance.....
I would agree.  So to be clear, we are talking about two issues that impact users with low vision.


1.    Use of CSS background  images that convey meaning but have programmatic names via properties such as aria-label

2.    Use of inline CSS images that convey meaning and have programmatic names via properties such as aria-label.

While these two issues may sounds the same – CSS images are supposed to be presentational and those background images are rightly removed in high contrast mode and when color are often turned off by the browser to improve reading contrast for users with low vision.  Inline images are considered non-presentational and thus are still displayed in these modes.

So, IMO the CSS background issue is a more egregious issue while the aria-label on inline images is lesser because at least the inline image is visually available.

Without any requirement for the user agent to display accessibility names for inline images it is problematic and raises accessibility support issues.

Use of presentation images with only programmatic indicators seems to meet like a failure – but WCAG doesn’t seem to address this under 1.1.1 or 1.3.1.  Seems like an oversight.  For example, WCAG WG thought wisely in SC 1.4.1 to require a visual indicator of color in addition to a programmatic one – but this didn’t carry over to CSS background images as 1.1.1 and 1.3.1 only require programmatic indicators and not visual.  I think the assumption is that everyone can interpret visual information or else they will be using assistive technology or a browser that has some accessibility feature that compensates.  While that is generally true – background images seem like a safe thing to remove as they are only for background purpose.  The problem is that people are using CSS background images to convey meaning because use of inline images have performance challenges.

Just my two cents.

Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
Phone 703.637.8957
Follow us: Facebook<http://www.facebook.com/#!/ssbbartgroup> | Twitter<http://twitter.com/#!/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Katie Haritos-Shea [mailto:ryladog@gmail.com]
Sent: Wednesday, March 25, 2015 9:45 PM
To: David MacDonald
Cc: WCAG
Subject: Re: Discussion of alt for CSS images


David,

Yes that is what I was referring to. I think this is a problem especially for low vision users - perhaps we have done a disservice to those users in this instance.....

* katie *

Katie Haritos-Shea @ GMAIL
On Mar 25, 2015 4:05 PM, "David MacDonald" <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
Hi Katie

Do you mean if for example if someone has images turned off, or if a file reference was wrong, the alt would appear in the space where the image is, but the aria-label won't?
If so, I've heard a few discussions of that on the HTML5 group. I think most would say that it is not a cross browser behaviour, and that some browsers show the alt, and others don't show the alt, and that browsers could show the aria-label if they wanted to.
The precedence which was set when we removed the requirement for alt on images if there is another means of reporting ACCNAME to the API, (which I was not particularly in favour of), sets a precedent that this behaviour of populating the empty image space with a visible alt, is not considered necessary for conformance by our Committee, and therefore not necessary for conformance here.


Cheers,

David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902<tel:613.235.4902>

LinkedIn<http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com<http://www.Can-Adapt.com>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Wed, Mar 25, 2015 at 12:49 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>> wrote:
David,

The other issue was what is visually apparent to users who do not use AT (concerning CSS images), but are not getting the images. There is not alt text. Any ideas on that issue?



* katie *

Katie Haritos-Shea
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545<tel:703-371-5545> | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545<tel:703-371-5545>

From: David MacDonald [mailto:david100@sympatico.ca<mailto:david100@sympatico.ca>]
Sent: Wednesday, March 25, 2015 12:34 PM
To: WCAG
Subject: Discussion of alt for CSS images

Reading through the minutes I see there was a discussion about CSS in images... it appears one concern is that it is not announced to screen readers as an image. Although I generally discourage the use or CSS images, if someone has to do them I suggest using role="image"
<div role="image" class="myPicture" aria-label="My dog fluffy looking happy">
This should announce to a screen reader that it is an image and the alternate text...


Cheers,

David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902<tel:613.235.4902>

LinkedIn<http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com<http://www.Can-Adapt.com>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Tue, Mar 24, 2015 at 12:32 PM, Marc Johlic <johlic@us.ibm.com<mailto:johlic@us.ibm.com>> wrote:
Minutes for the March 24, 2015 meeting:  http://www.w3.org/2015/03/24-wai-wcag-minutes.html




Thanks,
Marc


Marc Johlic | Accessibility Consultant - Web, Mobile, & Multimedia | IBM Accessibility | IBM Research




From:        Joshue O Connor <joshue.oconnor@cfit.ie<mailto:joshue.oconnor@cfit.ie>>
To:        WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Date:        03/20/2015 09:30 AM
Subject:        WCAG Agenda March 24 2015
________________________________



The WCAG WG will be meeting on Tuesday, 24 March 2015 at 11AM Eastern US

(Length: up to 90 minutes)

Bridge: +1.617.761.6200<tel:%2B1.617.761.6200>  (US) Passcode: 9224#

IRC: irc.w3.org<http://irc.w3.org><http://irc.w3.org<http://irc.w3.org/>>  port: 6665 channel #wai-wcag

Scribe list:https://www.w3.org/WAI/GL/wiki/Scribe_List


Survey/Agenda

1) WCAG F2F @ TPAC Sapporo, and comment responses etc
New survey https://www.w3.org/2002/09/wbs/35422/24thMarch2015/


2) Techniques work

3) Charter update

4) Reminder about outstanding actions

--
Joshue O Connor/Andrew Kirkpatrick
WCAG working group co-chairs