Re: Discussion of alt for CSS images

Hi dave,

code example from http://davidmacd.com/blog/css-background-images.html

<div class="bg-1" role="image" aria-label="my favorite kitten blah blah"
> tabindex="-1">
>

 role="image" is not an ARIA role the correct role=img [1], so it's not
going to work if that is the code you tested with.

[1] http://www.w3.org/TR/wai-aria-1.1/#img

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>

On 27 March 2015 at 20:53, David MacDonald <david100@sympatico.ca> wrote:

> As per my action items, here are testing results for CSS background and
> CSS inline images.
>
> http://davidmacd.com/blog/css-background-images.html
>
> Cheers,
>
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> 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 Fri, Mar 27, 2015 at 12:19 PM, James Nurthen <james.nurthen@oracle.com>
> wrote:
>
>>  not Jonathan but I think we are talking about things like
>>
>> #myid:before
>> {
>>  content:url('http://www.w3.org/2008/site/images/logo-w3c-screen-lg');
>> }
>>
>> Regards,
>> James
>>
>> On 3/27/2015 9:01 AM, David MacDonald wrote:
>>
>>  Hi Jonathan
>>
>>  I'm just throwing up some examples now... When you speak of "inline CSS
>> images", are you speaking about a regular <img ...> tag which is positioned
>> with CSS, or a CSS background image which has been positioned inline using
>> CSS?
>>
>>   Cheers,
>>
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>>
>> Tel:  613.235.4902
>>
>> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>>
>> 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 Thu, Mar 26, 2015 at 2:00 PM, Jonathan Avila <
>> jon.avila@ssbbartgroup.com> wrote:
>>
>>>  Ø  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
>>>
>>> Phone 703.637.8957
>>> Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> |
>>> Twitter <http://twitter.com/#%21/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>
>>> 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
>>>
>>> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> 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> 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 <703-371-5545> **|* *ryladog@gmail.com*
>>> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
>>> <http://www.linkedin.com/in/katieharitosshea/>*|* *Office: 703-371-5545
>>> <703-371-5545>*
>>>
>>>
>>>
>>> *From:* David MacDonald [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
>>>
>>> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> 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> 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>
>>> To:        WCAG <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  (US) Passcode: 9224#
>>>
>>> IRC: 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Regards, James
>>
>> [image: Oracle] <http://www.oracle.com>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
>> <+1%20415%20987%201918> | Video: james.nurthen@oracle.com
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood Cty, CA 94065
>> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
>> committed to developing practices and products that help protect the
>> environment
>>
>
>

Received on Saturday, 28 March 2015 09:23:09 UTC