- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 14 Mar 2013 00:33:55 +0100
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>
Steve Faulkner, Wed, 13 Mar 2013 11:13:59 +0000:
> 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.
If AX inspector is needed, then where s the better advice ... ?
> Voiceover announces the content of AXhelp after a use configurable delay.
Your aria-describedby example fails in released Safari+VoiceOver, in OX
10.7 and 10.8. But it does work in Webkit Nightly and in iCab. If your
aria-describedby solution worked, then the description would have
gotten repeated - such is at least VoiceOver’s behavior. To avoid that
problem, the instruction element can be hidden with aria-hidden="true".
(You could hide with @hidden as instead, but the keyboard users would
be out of luck if for instance CSS was disabled - which seems counter
to your motivation for fixing the spec.)
BT: To verify whether you experience aria-describedby or just source
order, you can add a line of text between label and the #instructions:
<label>Part number:<input … aria-describedby="instructions"></label>
—> <p>Text in between.</p> <—
<p id="instructions"> A part number …</p>
> If aria-labelledby is used one has to reference both the label and the
> description, it is a possible alternative but is more complex.
First: Didn't know. Sounds like a good point - as long as the total
solution works. For me it doesn't.
>> 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.
So? If the aria-describebedby referenced text is read, then it should
be read before AT gives the user a que to start writing - and not after
that que.
>> (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.
I have simplified. Following example uses 2 + 1 aria attributes, and
don't need CSS. (The '+ 1' is the space filled aria-label hack, which
has as similar effect on current release of Safari as a non-empty @alt
attribute on <img> - it causes the browser to not ignore the input
element. You perhaps don't need to show that hack in the spec - it
seems unnecessary in the Webkit nightly.)
<label>Part number:
<input pattern="[0-9][A-Z]{3}" name="part" aria-label=" " />
<span aria-hidden="true" >The part number is a digit followed
by three uppercase letters.</span>
</label>
Note again that that aria-hidden="true" is there in order to solve the
problem of the repeated instruction text. Not as well that you could
instead have used the @hidden attribute. But not that the the element
then would remain hidden form keyboard only uses if in CSS-disabled
browers. If you delete the aria-hidden="true", then users will get text
repeat instead.
Have not tested in Jaws or NVDA due to the amount of work that would
involve right not.
--
leif halvard silli
Received on Wednesday, 13 March 2013 23:34:25 UTC