- 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