Re: Proposal: Provide better advice on constraint validation instructions

Hi leif,

OS X 10.7 in Safari the content of an element referenced using describedby
is mapped to the AXhelp property. (this can be checked using the mac
accessibility inspection tool.

Voiceover announces the content of AXhelp after a use configurable delay.

If aria-labelledby is used one has to reference both the label and the
description, it is a possible alternative but is more complex.

If one get it to work - arial-labelledby or aria-describedby, then,
> unless one takes special care to hide the instruction when <input> does
> not have focus, the instructions are read twice - once together with
> <input> and once "alone". (Based on VoiceOver)
>

the typical scenario is that users are moving from control to control in a
form.

(4) In Safari+VoiceOver, the following would would work - and it has
> the advantage that @tite remains were it was:
>

I think this is an overly complex solution it may be appropriate in a
tutorial (if it works as you say), but the use of aria-hidden and CSS
generated content and ARIA roles, makes it more prone to cross
browser/cross OS issues, so it is not something that I would suggest
putting in the spec.



with regards

SteveF <http://www.paciellogroup.com/resources/wat-ie-about.html>
--
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
 <http://www.paciellogroup.com/resources/wat-ie-about.html>


On 13 March 2013 10:48, Leif Halvard Silli <
xn--mlform-iua.no@xn--mlform-iua.no.no> wrote:

> Steve Faulkner, Tue, 12 Mar 2013 10:05:15 +0000:
>
> > "the spec suggests user agents use the title attribute for description
> > strings that may be displayed at any time. Due to user agents not
> > implementing 'tooltips' accessibly, the content is not available to
> > keyboard only users until an incorrect pattern has been put in.
>
> > The methods I am going to recommend all involve adding the instructions
> in
> > text either as part of the label or associated vi aria-describedby :
>
> Regarding the aria-describedby example:
>
> (1) Why not aria-labelledby instead? In Safari+VoiceOver on OS X 10.7,
> there’s no effect of the aria-describedby in that example. That the <p>
> element is read after the <input> element is only because it follows
> after <input>. Aria-labelledby doesn't have those issues it has better
> support.
>
> (2) If one get it to work - arial-labelledby or aria-describedby, then,
> unless one takes special care to hide the instruction when <input> does
> not have focus, the instructions are read twice - once together with
> <input> and once "alone". (Based on VoiceOver)
>
> (3) Hiding when inactive would also fit well with @title, which has the
> advantage that it doesn't display until activated.
>
> (4) In Safari+VoiceOver, the following would would work - and it has
> the advantage that @tite remains were it was:
>
> <style>
> label{background:orange}
> input+span{display:none!important}
> input:focus+span{display:inline-block!important}
> </style></head><body>
>
>     <label> Part number: <input
>         pattern="[0-9][A-Z]{3}"
>                   title="The part number is a digit followed by three
>                          uppercase letters."
>                  id="a"
>     aria-labelledby="a"
>                name="part" />
>     <span aria-hidden="true" role="separator" id="b" >The part
>     number is a digit followed by three uppercase letters.</span>
> </label>
>
>
> > I envisage that this advice can be modified to recommend use of the title
> > attribute at a time when it is interoperably implemented in an input
> device
> > independent way.
>
> Are you here speaking about HTML5 vs HTMl5.1? There is already one
> implementation - Webkit - which can, via CSS, render the @title of the
> <input> element when it has keyboard focus.
>
> The spec’s test suite usually tests things that the specification
> require implementations to support. So if the current examples are just
> removed, then the test suite is not obligated to test keyboard access
> to input’s @title attribute - or? And thus we might not see progress on
> this issue. Are there other parts of the spec which can be used to
> track keyboard accessibility progress w.r.t. @title?
> --
> leif halvard silli

Received on Wednesday, 13 March 2013 11:15:17 UTC