- From: David MacDonald <david100@sympatico.ca>
- Date: Sat, 28 Mar 2015 12:30:41 -0400
- To: "james.nurthen@oracle.com" <james.nurthen@oracle.com>
- CC: Mike Elledge <melledge@yahoo.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
- Message-ID: <BLU437-SMTP64F4071C09BFA7B15DD790FEF70@phx.gbl>
Urrrg... ! You are so right James... that did it... we have to get Gez to add that... 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 Sat, Mar 28, 2015 at 11:59 AM, james.nurthen@oracle.com < james.nurthen@oracle.com> wrote: > Have you made sure to start JAWS before you start Firefox? > > > On Mar 28, 2015, at 8:28 AM, David MacDonald <david100@sympatico.ca> > wrote: > > Hi Mike > > JAWS16 read the aria-label and role="img" fine in Chrome in the example > but IE and FF are not reading them. > > I've actually stopped using JAWS and FF, because it doesn't seem to go > into Browser mode. > I've tried all the fixes here > http://juicystudio.com/article/handling-erratic-behaviour-at.php > > So if someone has their JAWS and FF running well together perhaps they can > confirm my results. > > 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 7:24 PM, Mike Elledge <melledge@yahoo.com> wrote: > >> This is very interesting, David. I know you asked that others check the >> JAWS interactions, but are accessibility problems most often with JAWS and >> IE together? I had assumed (perhaps unfairly) the culprit was most often IE >> alone. >> >> Mike >> >> >> >> On Mar 27, 2015, at 4:53 PM, 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 >>> >>> <oracle_sig_logo.gif> <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 >>> <green-for-email-sig_0.gif> <http://www.oracle.com/commitment> Oracle >>> is committed to developing practices and products that help protect the >>> environment >>> >> >> >
Received on Saturday, 28 March 2015 16:31:13 UTC