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

 That's why  in my email I
 suggested one should read the notes on the page.
 Indeed the error message should be associated with the form
 control but I did this to  demonstrate usage of
 alt+describedby with the form control having a tooltip
 already associated by aria-describedby.
 And simply setting aria-invalid only leads to needless
 verbosity if the error text and suggestion for fix are
 associated with the control. Aria-invalid is alright when no
 other text is needed to indicate presence of error / fix
 Thanks,
 Sailesh
   
   
 --------------------------------------------
 On Tue, 11/26/13, Hoffman, Allen <allen.hoffman@hq.dhs.gov>
 wrote:
 
  Subject: RE: UNS: RE: UNS: WCAG considering amending F65 to
 NOT fail missing   ALT text if title or
 aria-label is present
  To: "Marco Zehe" <mzehe@mozilla.com>,
 "Sailesh Panchang" <spanchang02@yahoo.com>
  Cc: "David MacDonald" <david100@sympatico.ca>,
 "Joshue O Connor" <joshue.oconnor@cfit.ie>
  Date: Tuesday, November 26, 2013, 10:43 AM
  
  Just from my personal perspective as
  a screen reader user from when they were invented:
  
  
  The practice of inserting tabs for screen reader users so
  they can read non-interactive information is great for us
  screen reader folks and to us makes perfect sense, but
 does
  seem like a completely goofy thing for anyone else using
 the
  page.  Information associated with elements should be
  navigable by screen reader users in a sensible way, but
  should be tied closely to the elements it goes with as
  well.  At some point if we are really moving to a
  rich-interactive interface then we have to accept some
 usage
  change from the less rich formats we've become used
  to.    
  
  
  
  -----Original Message-----
  From: Marco Zehe [mailto:mzehe@mozilla.com]
  
  Sent: Tuesday, November 26, 2013 10:33 AM
  To: Sailesh Panchang
  Cc: David MacDonald; Joshue O Connor; 'HTML Accessibility
  Task Force'; 'WCAG WG'
  Subject: 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 16:26:18 UTC