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

On 11/27/2013 10:28 AM, Sailesh Panchang wrote:
> The Techniques doc
> http://www.w3.org/TR/WCAG20-TECHS/
> should first document this as a sufficient ARIA technique for SC 1.1.1 before the failure can be documented.
Why? I don't propose documenting this as the best way of doing anything. 
IMO alt is the best way to provide a text alternative for content in 
HTML so documenting a sufficient technique for aria-label etc. doesn't 
seem like a good idea. Remember that authors need not use any of the 
sufficient techniques in order to create conforming content but they may 
use one of their own techniques which is accessibility supported.

Failures are different in that any content which "meets" the failure 
fails the success criteria. My argument is that content which clearly 
meets the success criteria by providing a text alternative should not 
automatically fail just because it does not use one particular 
technique. I thought the whole directive behind WCAG2 was that it was 
technology agnostic and was trying to document outcomes rather than 
specific methods of getting to that outcome.

>
> As commented in the survey feedback,  it is important to provide guidance to developers when two or more attributes for text alt are present in the code. I suppose both alt and aria-labelledby / aria-label / title should be identical. Aria-describedby should be different from the alt.
Yes - it is important. A specific failure for alt text is not the place 
to do so. If we think this can be documented into a failure then perhaps 
a different failure would be appropriate.

>
> Yet,
> I have read and re-read the Intro to Aria
> http://www.w3.org/TR/wai-aria/introduction
> and every time come away with the  conclusion that  ARIA is meant for rich content that cannot be marked ordinarily by HTML only. And these elements are interactive elements that have role, state, attributes besides name, description. The ARIA specs repeatedly identifies these as objects or custom widgets:
> "The incorporation of WAI-ARIA is a way for an author to provide proper semantics for custom widgets to make these widgets accessible, usable, and interoperable with assistive technologies. This specification identifies the types of widgets and structures that are commonly recognized by accessibility products,..."
> A critical ingredient is the "role", so when one repurposes a standard HTML element as something with a new role, ARIA kicks in.
> "Roles are a common property of platform accessibility APIs
>   which assistive technologies use to provide the user with effective presentation and interaction. This role taxonomy includes interaction widgets and elements denoting document structure."
> "States and properties are used to declare important attributes of an element that affect and describe interaction."
> So "interactivity" seems to course through every vein of ARIA.
> And there's lot of rich interactive content  that can be made accessible with ARIA  when browsers and AT implement the specs uniformly.
> That's where efforts should be focussed.
> So from the reading of the ARIA specs I do not think fixing the alternative text for a plain non interactive image is its primary goal.
Of course it is not its primary goal. However, the spec allows this 
usage. I'm not sure how you draw the interpretation that a spec which 
has roles for various document elements such as heading, img, list, 
listitem, math etc. is only concerned with interactive widgets. The 
global states and properties such as aria-label and aria-labelledby are 
clearly stated in the spec that they are "applicable to all host 
languageelements 
<http://www.w3.org/TR/wai-aria/terms#def_element>regardless of whether 
arole <http://www.w3.org/TR/wai-aria/terms#def_role>is applied "



>
> A bigger concern is the accessible name / text alternative computation  logic (identified as a feature at risk):the logic makes the ARIA attributes take precedence over native elements / attributes. The logic is fine for elements that have been repurposed with a new ARIA role; else the native markup should take precedence.
That is not how it is defined. If you had an objection based on this the 
time to have made it would have been during the last call of the ARIA 
specification. This has now passed and the spec is at the point of 
testing the implementations in order to make sure the spec is implementable.

>
> Regards,
> Sailesh Panchang
>
> --------------------------------------------
> On Wed, 11/27/13, James Nurthen <james.nurthen@oracle.com> wrote:
>
>   Subject: Re: WCAG considering amending F65 to NOT fail missing ALT text if title or aria-label is present
>   To: "RichardWarren" <richard.warren@userite.com>
>   Cc: "Marco Zehe" <mzehe@mozilla.com>, "Detlev Fischer" <detlev.fischer@testkreis.de>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>, "WCAG" <w3c-wai-gl@w3.org>, public-comments-wcag20@w3.org
>   Date: Wednesday, November 27, 2013, 11:21 AM
>   
>   F65 is a
>   Failure Technique for 1.1.1. It is stating that if you fail
>   F65 then you fail 1.1.1
>   1.1.1 States"All non-text
>   content that is presented to the user has a text
>   alternative that serves the equivalent purpose, except
>   for the situations listed below..... "
>   
>   The definition of text alternative in WCAG is
>   "Text that is programmatically associated
>   with non-text content or referred to from text
>   that is programmatically associated with non-text content.
>   Programmatically associated text is text whose location
>   can be programmatically determined from the non-text
>   content."
>   I'm don't see how a missing alt text,
>   when the text alternative is supplied by another means such
>   as aria-label, aria-labelledby or even title, fails 1.1.1 -
>   assuming they are accessibility supported.
>   Regards,James
>   
>   
>   On Nov 27, 2013, at 3:54 AM, RichardWarren <richard.warren@userite.com>
>   wrote:
>   
>    
>   
>   
>   
>   I fully agree with Marco,
>    
>   >> I now
>   declare that I firmly stand with the opinion that F65 should
>   NOT be softened.
>   >>
>    
>   Alt attributes are simple, clear, easy to use and
>   understand, compatible
>   with accessibility software and tools.
>    
>   Richard
>   
>   
>    
>   
>   From: Marco
>   Zehe
>   Sent: Wednesday, November 27, 2013 8:18 AM
>   To: Detlev
>   Fischer
>   Cc: David MacDonald
>   ; HTML
>   Accessibility Task Force ; WCAG ; public-comments-wcag20@w3.org
>   
>   
>   Subject: Re: WCAG considering amending F65 to
>   NOT fail missing ALT
>   text if title or aria-label is present
>    
>   
>    
>   
>   On Nov 26, 2013, at 9:53 PM, Detlev Fischer <detlev.fischer@testkreis.de>
>   
>   wrote:
>   
>   The
>   
>     intended change of F65 is driven by the aim to publish
>   more ARIA Techniques to
>     establish ARIA as part of the toolbox, hopefully to be
>   picked up by devs to
>     make all sorts of fancy web stuff more accessible. I
>   believe that this will be
>     seen as rightful aim by most - after all, we can't
>   stop the fancy stuff out
>     there, we can only hope to provide the means to make it
>   accessible. If the
>     ARIA Techniques help doing that, this also requires some
>   revisiting of Common
>     Failures to even out the inconsistencies that Jared has
>   pointed out. (To be
>     more precise, this is necessary if we stick to the rule
>   that finding a failure
>     in the test of a Failure Technique will fail the SC in all
>   cases.)
>   
>    
>   Hi all,
>    
>   one thing to consider is that, if a web developer
>   isn't going to put alt on
>   an image, they're just as unlikely to put aria-label on
>   it. There is a
>   bullet-proof way to make images accessible, which is
>   backwards compatible into
>   the 90s. There simply is no reason to soften F65 in my
>   opinion, by allowing ARIA
>   on an image. Alt text is established, and those familiar
>   with accessibility
>   including ARIA are also familiar with alt text.
>    
>   I agree with janina's comment about ARIA not going
>   away, but it should also
>   be not the catch-all solution for just anything. It has a
>   specific purpose, to
>   bridge gaps, and that's what it is doing. And an img tag
>   is nothing new, nor is
>   it something fancy, and there is an established way to make
>   it accessible.
>    
>   So despite my earlier concerns re CSS background
>   images, I now declare that
>   I firmly stand with the opinion that F65 should NOT be
>   softened.
>    
>   CSS background images and so forth are discussions for
>   other types of
>   success criteria and deserve their own topic.
>    
>   Marco
>    
>   Richard
>   Warren
>   Technical Manager
>   Website Auditing Limited (Userite)
>   http://www.website-accessibility.com
>    
>   
>