Re: UNS: RE: UNS: WCAG considering amending F65 to NOT fail missing ALT text if title or aria-label is present

Right Marco. Here is an example of tab-navigable error icon with alt+ aria-describedby.
http://mars.dequecloud.com/demo/form-alert2.htm
Submit the form to see the error icons.
(Please read the notes if you have the time)
And if one uses alt="Eiffel tower and an aria-labelledby that references some other text, there is the distortion in image identification.
So that's why I maintain one does not have to make  the simplest problem in accessibility of labelling an image so complex that it impacts end users and testers and leaves developers scratching their heads. So do not change F65.
Regards,
Sailesh

--------------------------------------------
On Tue, 11/26/13, Marco Zehe <mzehe@mozilla.com> wrote:

 Subject: Re: UNS: RE: UNS: WCAG considering amending F65 to NOT fail missing   ALT text if title or aria-label is present
 To: "Sailesh Panchang" <spanchang02@yahoo.com>
 Cc: "David MacDonald" <david100@sympatico.ca>, "Joshue O Connor" <joshue.oconnor@cfit.ie>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'WCAG WG'" <w3c-wai-gl@w3.org>
 Date: Tuesday, November 26, 2013, 9:43 AM
 
 Hi all,
 
 to clarify how screen readers use aria-describedby, or more
 in general, the thing called AccDescription as opposed to
 AccName:
 When you browse a page in JAWS, NVDA, or any other screen
 reader with a virtual buffer concept, the accessible name of
 an image will be picked up, put in the buffer, along with
 the semantic information that this is a graphic, or image.
 What will *not* happen, is that accDescription will be
 picked up. AccDescription will *only* be picked up on a
 *focused* element when tabbing to it and speaking the
 focused item. So a link that has both text and title, where
 the title becomes the accDescription, will be spoken as the
 text plus the indicator for a link, followed by the bit
 provided by AccDescription.
 If you provide a description on an image via
 aria-describedby, users will never be notified of it because
 images, unless they are part of a link construct, will never
 receive focus by default. What's in an AccDescription for an
 image will simply be ignored inside the virtual buffer.
 
 Other screen readers such as VoiceOver on Mac and iOS may
 pick this up and report it, just because VoiceOver's concept
 is to put its own version of the focus on anything. Firefox
 for Android and Firefox OS will probably do the same for
 images, since on touch screen devices, the lines between
 what is focused/focusable or not are very weak compared to
 the desktop.
 
 Again: If aria-describedby is being used on an image,
 chances are very high that screen readers on Windows, while
 the user browses a page, will simply ignore whatever is
 provided though that mechanism.
 
 Marco
 
 On Nov 26, 2013, at 3:35 PM, Sailesh Panchang <spanchang02@yahoo.com>
 wrote:
 
 > David / Joshue,
 > This solution about aria-describedby  has been in
 the survey comments for two weeks now and I had drawn
 attention to it during the call too: 
 > "iii. On  reflection, I think it is always better
 to use aria-describedby on the alt (instead of
 aria-labelledby). The intent is to have available text on 
 > the page announced without need for duplicating and
 also to avoid pitfalls of not assigning an alt or using
 alt="". So the alt can be say, a single word and the more
 descriptive text elsewhere on the page. Then both will be
 read. For instance the alt can be "Logo:" and the
 aria-describedby can be the org's name say at the top of the
 page. In the star rating example (on aria-labelledby example
 for image), the alt can be "Rating:" and the other text can
 be "3 /5" etc. So if we adopt this approach, we should not
 advocate use of aria-labelledby for images." 
 > 
 > Using aria-describedby in this way helps to enhance
 accessibility / user experience. It does not distort 
 the way different user groups identify the image if
 aria-labelledby were used .... a point I made earlier too
 and is illustrated in David's code sample:
 > <img scr="eiffelTower.jpg" alt="Eiffel tower"
 labelledby="123">
 > <p id="123"> The tower stands 324 metres (1,063
 ft.) tall</p>
 > 
 > Is this not a concern? Or is the focus only on ARIA
 supported AT users?
 > Again the focus of ARIA is on rich Internet apps /
 content. The algorithm's focus is clearly on 
 interactive elements as per the examples.
 > Thanks and regards,
 > Sailesh
 > 
 > 
 > 
 > 
 > --------------------------------------------
 > On Tue, 11/26/13, Joshue O Connor <joshue.oconnor@cfit.ie>
 wrote:
 > 
 > Subject: Re: UNS: RE: UNS: WCAG considering amending
 F65 to NOT fail missing   ALT text if title
 or aria-label is present
 > To: "David MacDonald" <david100@sympatico.ca>
 > Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>,
 "'WCAG WG'" <w3c-wai-gl@w3.org>
 > Date: Tuesday, November 26, 2013, 6:30 AM
 > 
 > David MacDonald wrote:
 >> There are several fixes, here are two:
 >> 1) use aria-describedby insread of aria-labelledby
 > because it maps to the
 >> accDescription, not the accName, so the alt gets
 the
 > accName and the
 >> describedby gets accDescription
 >> 2) leave off the aria-labelledby, so the user will
 hear
 > the ALT text, and
 >> encounter the supplementary text in the paragraph
 after
 > the image.
 > 
 > Thanks, and if you find a suitable spot in one of our
 wikis
 > that'd be great (if not already there somewhere). Also
 maybe
 > also overviews of what accName/accDescription are -
 most
 > designers don't think on this level at all.
 > 
 >> If the algorithm does not shift from OR to AND,
 then we
 > will need to
 >> introduce WCAG failures for the presence of both
 > ALT+aria-label, and
 >> ALT+aria-labelledby in an image.
 > 
 > <chair hat off> Maybe, maybe not. We really have
 to
 > discuss these things on a case by case basis.
 Accessible
 > development techniques and UA support are always
 changing,
 > so some caution is needed - (this is part of the reason
 we
 > are having this unforeseen @alt debate, no?). Ideally,
 the
 > standard should define the behaviour but as we know in
 > practice that's just not always the case.
 > 
 > Thanks
 > 
 > Josh
 > 
 > 
 >

Received on Tuesday, 26 November 2013 15:17:49 UTC