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

Hi Sailesh,

yes, this one works technically, however if someone asked me whether they should code a form this way, I would always tell them to *not* do it this way. And here's why:

1. The extra tab stops are annoying.
2. The bulleted list is directly prepended to the form itself, so one has to go past them to get to the form itself, and then get the items re-read when focusing on the images.
3. Instead of having these extra tab stops, it would make much more sense to have the descriptions directly attached to the form field, and also clear them once the validation succeeds, so the information is directly linked contextually. This would not increase the number of tab stops, but still keep the error messages linked to the form fields they apply to.

So, while it is technically correct to put these images there, make them focusable and so forth, usability-wise I, as a screen reader user who would have to deal with this form, would find it distracting to suddenly have a different tab order here. Moreover, since I have a modern browser, I would have expected more HTML5 validation, e. g. the input fields having a real "invalid" attribute and the validation happening directly while I was typing my info. That way, the error messages could be applied dynamically, so when re-checking the form before submitting, I would get the error messages automatically before even submitting.

But maybe that's just me…

Marco

On Nov 26, 2013, at 4:17 PM, Sailesh Panchang <spanchang02@yahoo.com> wrote:

> 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 17:53:32 UTC