This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16804 - [AAPI]: take into account for title attribute specialness when on input that also accepts required
Summary: [AAPI]: take into account for title attribute specialness when on input that ...
Status: NEW
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y APIs (editor: Steve Faulkner, Cynthia Shelly) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML a11y API spec bugbot
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2012-04-19 20:49 UTC by steve faulkner
Modified: 2018-10-09 00:19 UTC (History)
8 users (show)

See Also:


Attachments
screenshot of chrome implementation (16.49 KB, image/png)
2012-04-24 11:19 UTC, steve faulkner
Details

Description steve faulkner 2012-04-19 20:49:53 UTC
"5. Accessible Name and Description calculation"
see http://dev.w3.org/html5/spec/common-input-element-attributes.html#attr-input-pattern for details of title attribute specialness
Comment 1 alexander surkov 2012-04-23 03:40:40 UTC
Steve, what is the proposal? What's difference from http://www.w3.org/TR/html-aapi/#inputs
Comment 2 steve faulkner 2012-04-24 11:19:50 UTC
Created attachment 1123 [details]
screenshot of chrome implementation
Comment 3 steve faulkner 2012-04-24 11:22:13 UTC
(In reply to comment #1)
> Steve, what is the proposal? What's difference from
> http://www.w3.org/TR/html-aapi/#inputs

the title attribute is used as the source for text that is displayed in erro messages (as per HTML5 spec http://dev.w3.org/html5/spec/common-input-element-attributes.html#attr-input-pattern ) as well as appearing as a tooltip this is implemnted in chrome canary(see attached screenshot)
So i think this needs to be taken into account, thoughts?
Comment 4 alexander surkov 2012-04-24 13:43:06 UTC
do you mean we need a mechanism other than classical mapping to accessible name and description?
Comment 5 David Bolter 2012-04-24 13:46:56 UTC
Is this really about the pattern attribute?
Comment 6 steve faulkner 2012-04-24 13:47:47 UTC
(In reply to comment #4)
> do you mean we need a mechanism other than classical mapping to accessible name
> and description?

thats what i don't know, which is why i have raised the issue. as you can see from the screenshot the text is displayed in 2 places (tooltip and error message). how will this be handled to avoid repetition?
Comment 7 steve faulkner 2012-04-24 13:48:45 UTC
(In reply to comment #5)
> Is this really about the pattern attribute?

?
Comment 8 steve faulkner 2012-04-24 13:52:04 UTC
(In reply to comment #7)
> (In reply to comment #5)
> > Is this really about the pattern attribute?
> 
> ?

actually as implemented in chrome it occurs if required attribute is present, not contingent on the pattern attribute
Comment 9 David Bolter 2012-04-24 14:21:20 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > Is this really about the pattern attribute?
> > 
> > ?
> 
> actually as implemented in chrome it occurs if required attribute is present,
> not contingent on the pattern attribute

OK I wondered if you really meant to link to the pattern part of the spec in comment 0.
Comment 10 steve faulkner 2012-04-24 14:37:05 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #5)
> > > > Is this really about the pattern attribute?
> > > 
> > > ?
> > 
> > actually as implemented in chrome it occurs if required attribute is present,
> > not contingent on the pattern attribute
> 
> OK I wondered if you really meant to link to the pattern part of the spec in
> comment 0.

yes i did, as it defines how title should be used and implemented
Comment 11 alexander surkov 2012-04-25 04:33:33 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > do you mean we need a mechanism other than classical mapping to accessible name
> > and description?
> 
> thats what i don't know, which is why i have raised the issue. as you can see
> from the screenshot the text is displayed in 2 places (tooltip and error
> message). how will this be handled to avoid repetition?

Ok, I'd say it should be implementation dependent. For example, if that message is shown when user left the text field with incorrect value then I'd say we should map it into alert so it gets announced to the user immediately.

Btw, I'm a little bit confused by chrome screenshot. Why are message and tooltip shown the same time? What is markup of this case?
Comment 12 Michael[tm] Smith 2012-04-25 10:19:59 UTC
Testing to see if problme Alex describes in bug 16850 happens.
Comment 13 steve faulkner 2012-04-25 10:25:57 UTC
(In reply to comment #11)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > do you mean we need a mechanism other than classical mapping to accessible name
> > > and description?
> > 
> > thats what i don't know, which is why i have raised the issue. as you can see
> > from the screenshot the text is displayed in 2 places (tooltip and error
> > message). how will this be handled to avoid repetition?
> 
> Ok, I'd say it should be implementation dependent. For example, if that message
> is shown when user left the text field with incorrect value then I'd say we
> should map it into alert so it gets announced to the user immediately.
> 
> Btw, I'm a little bit confused by chrome screenshot. Why are message and
> tooltip shown the same time? What is markup of this case?

In chrome the title attribute text is shown both in the tootltip (anytime) and in the error message when triggered.
Comment 14 alexander surkov 2012-04-25 10:32:49 UTC
Ok. I think when error message is shown then it should be mapped to alert. Tooltip itself should be processed as usual. I'm not sure whether the spec should address that since it's implementation dependent.