Re: no-title CP - remarks

hi leif, thanks for the comments,

>SteveCP: "Browser vendors have not made a commitment to provide device
>independent access to title attribute content"
  >Leif: They have committed themselves to ARIA. ARIA does use @title
>as last resort. And the issue on the agenda *is* @title as last resort.
>The agenda is not access to @title when there *is* @alt. Hence, this
>argument seems weak.

title has been used as the accessible name for a long time and I have been
well aware of this
here is some results of tests i conducted in 2005
http://www.paciellogroup.com/resources/articles/WE05/forms.html

As i pointed out on the call today, I am referring to input device
independence, think UAAG or section 508 1194.21
ie Keyboard Accessibility.

> Leif: (1) there were no negative answers - which is what the
>Decision called for. Charles from Opera showed themselves capable of
>solving the issue. And Webkit is not much behind Opera when it comes to
>doing the same CSS trick that Charles showed w.r.t. Opera.

using a CSS trick does not mean the user agent provides keyboard access to
title attribute content, user agents don't and NONE have commited to doing
so.

 > (2) Device independent access is not 100% on the matter, since
>we are discussing a last resort requirement, where the UA has the
>option of helping the user.

keyboard access to title attribute content is 100% of the matter.


>Leif: The last years have given us more OSes and more mobile phone
>browsers = there are more implementations. Can this really be taken as
>evidence that the number of implementations supporting @title in an
>accessible way has decreased? The increased use of Webkit has lead to
>more display of @title when @alt is lacking.

with the increase in mobile and touch interfaces there are more browsers
deployed that do not display title attribute content period, webkit based
mobile browsers ONLY show title when images are disabled

>Leif: If screenreaders treat the two images the same, then that
>sounds like an argument in support for the Decision: we are not faced
>with a situation where they do not get access to some fallback for the
>image.

the point is that the fallback is not a text alternative BUT there is no
indication that it is not the semantics are ambiguous.

> Leif: Unclear. I disabled images in Opera, hovered above where image
>was supposed to be - and voila

voila only for mouse users.

apologies,  don't have any more time to respond to your further comments at
this time.


regards
steve

On 9 May 2011 19:58, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>wrote:

> So, on the subgroup call today, I was in minority regarding Steve's
> @title CPS. Here are some comments regarding Steve's CP shaped as a
> critique. Please do at least see it as a devil's lawyer type of comment.
>
> Steve's CP: http://www.w3.org/html/wg/wiki/ChangeProposals/notitle
>
> Simply put, I think I agree with Maciej when it comes to how browses
> should behave. But I agree with Steve with regard to what should be
> conforming.
>
> Comments.
>
> SteveCP: "Browser vendors have not made a commitment to provide device
> independent access to title attribute content"
>   Leif: They have committed themselves to ARIA. ARIA does use @title
> as last resort. And the issue on the agenda *is* @title as last resort.
> The agenda is not access to @title when there *is* @alt. Hence, this
> argument seems weak.
>
>        == Chairs asked for: "Evidence that the number of implementations
> exposing title in an accessible way is decreasing, or that some
> existing implementations are unwilling or unable to expose it in an
> accessible way." ==
>
> SteveCP: lists some answers from Apple, Opera, Microsoft, Firefox and
> concluded that "So no vendors have indicated any plans to implement
> device independent access to title attribute content as a feature."
>   Leif: (1) there were no negative answers - which is what the
> Decision called for. Charles from Opera showed themselves capable of
> solving the issue. And Webkit is not much behind Opera when it comes to
> doing the same CSS trick that Charles showed w.r.t. Opera.
>         (2) Device independent access is not 100% on the matter, since
> we are discussing a last resort requirement, where the UA has the
> option of helping the user.
>
> SteveCP: 'The display of title attribute content in both browsers and
> OS's has decreased markedly in the last 5 years due to the increase in
> mobile browsers and touch interfaces. No mobile browsers are known to
> display title attribute content.'
>   Leif: The last years have given us more OSes and more mobile phone
> browsers = there are more implementations. Can this really be taken as
> evidence that the number of implementations supporting @title in an
> accessible way has decreased? The increased use of Webkit has lead to
> more display of @title when @alt is lacking.
>
> SteveCP: 'All browsers (except Safari on Mac, but the difference in
> mapping does not equate to the two being differentiated by VoiceOver)
> treat these 2 cases the same in regards to accessibility API mapping:
> [<img title=foo> <img alt=foo>] [ snip ] for a screen reader user there
> is no difference in how the two are presented to the user and no
> differentiation method is suggested or defined.
>   Leif: If screenreaders treat the two images the same, then that
> sounds like an argument in support for the Decision: we are not faced
> with a situation where they do not get access to some fallback for the
> image.
> SteveCP: '[ snip ] alt attribute [ snip ] normativley described, while
> for the title attribute there are no normative restrictions:'
>   Leif: This is supposed to tell us why @title should not be
> conforming. And it is one of the best parts of the CP. HOwever, the
> Decision - in contrast - say that *because* @alt has so strict rules,
> then, when the author finds that he/she is unable to write a proper
> @alt text, he/she should at least provide a @title.
>
> SteveCP: 'Most Graphical browsers do not display title text when images
> are not displayed'
>   Leif: Unclear. I disabled images in Opera, hovered above where image
> was supposed to be - and voila, in contrast to what Steve says, it
> displayed. It is the same in Firefox, provided CSS gives the element
> dimensions. Thus, this is more question about 'device independent
> access' than about 'display'.
>   Leif: Did you meant that most graphical UAs don't display the @title
> as if it was an @alt?
>   Leif: It should not be hidden under the carpet that most text
> browser do display @title when @alt is lacking.
>   Leif: According to Richard, an image with a non-empty @title is
> non-presentational, regardless of its @alt. So  is it correct to hide
> an img without @alt completely? (Opera does not hide an image without
> @alt - it instead display a repair text - and other browsers tends to
> at least provide a fallback-icon, which allows you do display @title by
> hovering above it.)
>
> SteveCP: 'Results from testing in popular browsers showed that in all
> browsers except Safari title attribute text is not displayed when a
> image is missing or not displayed.'
>   Leif: Please replace 'Safari' with 'Webkit based browsers'. And note
> that this is a category of browsers that is expanding.
>
> StevePC: 'So user agents cannot display alt as a tooltip because it
> promotes bad authoring behaviour, but authors can use now use the title
> attribute to achieve the same result: text that is shown as a tooltip
> AND in place of an image when it is not rendered AND as the accessible
> name for the image in APIs. This makes no sense.'
>   Leif: I agree that some authors might not grok the difference
> between @title and @alt if @title is displayed like @alt. However, a
> compromise could be to make validator whine when @alt is lacking. This,
> in turn - the chairs are probably reasoning - could lead to authors
> inserting empty @alt, to be valid. Which raises another question:
> should it validate to have an empty @alt together with an non-empty
> @title? Or perhaps the empty @alt in such cases shouldn't be respected?
> (We are far to much wedded to the the idea that an empty @alt is
> supposed to be equal to role=presentation - it doesn't match reality.)
>
> StevePC: ' plans to follow webkit's lead' ? Chaals reply: "I don't
> believe we have any such plan (I hope not, too)."
>   Leif: Why not allow UAs to repair for lack of @alt using @title
> instead of the 'Image' text that Opera now uses?
>
> Leif H Silli
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html