no-title CP - remarks

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

Received on Monday, 9 May 2011 18:58:37 UTC