Show & hide form help text - Links inside labels.
Home / Site Building & Testing / Show & hide form help text - Links inside labels.
I need to know how screen readers deal with links inside labels.
I've recently written a short piece of script to show & hide additional help when using forms.
The link to the extra help is inside the explicit form label, as is the extra help itself.
Reference: Accessible JavaScript; Form help; A show & hide technique
I believe that a screen reader will read the whole label, including the extra help, with or without JavaScript.
But what sense does a screen reader generate of links inside labels?
And what action is taken, follow link, or focus on the form control?
As usual all help, comment and critique gratefully received.
mike 2k:)2
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share: 
I'd say you're misusing elements by placing text inside the label which isn't exclusively to do with the activating/deactivating/focussing (or necessity) of that specific form control.
Better, imho, to place the help option either directly before or after that form control (i.e. not inside that form control's label).
You should make the help link text clear as to which form control it relates to, but squeezing it into that form control's label is, imho, the wrong thing to do.
Share:
Hi Bill,
Thanks for taking a look, but I respectfully disagree at present.
Though ensuring the help link forms a small part of the visible label, not the whole as present is a good point.
Perhaps:
| Code: |
| <label>Total amount to insure:
<span class="helpLink">[help]</span> <span>Help text ... |
would be more correct?
mike 2k:)2
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
The issue/problem as I see it is that the label text (i.e. any text nested within the label element) also functions as a means to focus that form control.
Now, please do correct me if I'm wrong, but as I understand it, this potentially means that keyboard users (etc…) who alight upon the label text will have the focussed passed directly onto the form control, bypassing the help link.
| W3C wrote: |
| The LABEL element is used to specify labels for controls that do not have implicit labels, |
Yes, you're trying to create a function/facility that relates to a particular form control element, but it's not technically part of - or does not fall within the prescribed function of - the label.
I'm not sure that I see why you feel that it should/must be within the same label element. It's unlikely that the label was ever intended to be used in that way and, due to its pecularities, I'm not altogether sure that it's an element which will handle the particular task you're setting upon it with either grace or consistency - particularly for those not using pointing devices.
Share:
| Bill Posters wrote: |
|
Now, please do correct me if I'm wrong, but as I understand it, this potentially means that keyboard users (etc…) who alight upon the label text will have the focussed passed directly onto the form control, bypassing the help link. |
That's my understanding too.
http://www.w3.org/...
I'd have the label, the form control and then a link to the help for that control.
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
Sorry Bill,
| Bill wrote: |
| Now, please do correct me if I'm wrong, but as I understand it, this potentially means that keyboard users (etc…) who alight upon the label text will have the focussed passed directly onto the form control, bypassing the help link. |
| eatyourgreens wrote: |
| That's my understanding too.
http://www.w3.org/... I'd have the label, the form control and then a link to the help for that control. |
A keyboard user does not access a label, just the form control (and links).
That is unless every label has an access key assigned [pointless but another topic].
Though this does raise another valid issue.
Give the link focus for keyboard users:
Ammendment 2.
Change the anchor into a link.
| Code: |
| anchor.name='#help' |
To
| Code: |
| anchor.href='#help' |
So the link recieves focus via keyboard for keyboard users.
| Bill wrote: |
| I'm not sure that I see why you feel that it should/must be within the same label element. It's unlikely that the label was ever intended to be used in that way and, due to its pecularities, I'm not altogether sure that it's an element which will handle the particular task you're setting upon it. |
The visible label and the hidden help text are both implicitly and explicitly associated to the form control.
This gives users of screen-readers the help information before they reach the form control.
It is very bad practice to place help text after a form control with the exceptions of radios and checkboxes.
Ammendments 1 & 2 are now live
mike 2k:)2
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
Bottom line: it's not actually label text, so…
The label element is not there to house anything and everything that's associated with a particular form control.
Some controls may well require - or benefit from - addition explanatory text, but (imo) that text would belong before the form control (or possibly in a dedicated help footnote/document), but not within that control's label text.
Share:
The problem that we face Bill is that if you place the text outside the of the label and the user is in "forms mode" of their screen reader then the help link/text link will not be read out._________________
Alex
Share:
The "bottom line" is; Does the method improve accessibility or reduce it?
I firmly believe it does by resolving one issue that plagues accessible form designers.
Not 100% for all form help by any mark, but it does help.
The original question:
What sense is generated by screen-readers when accessing a link inside a label?
Though these side issue discussions have already proved useful, I thank you all.
mike 2k:)2
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
A couple of observations on the example code:
- When I click the text 'total amount to insure' and start to type, my typing doesn't appear in the text box because it doesn't receive focus. Instead, the help text appears and disappears, so the label is no longer acting as defined by the HTML spec.
- Since you're changing an element from display:none to display:inline without reloading the page, will a screenreader actually pick up this change, or will it continue to ignore the hidden text?
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
eatyourgreens:
1. Refresh the page, that was Ammendment 1.
2. Screen readers read all form elements regardless of display state.
mike 2k:)2
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
| mike 2k:)2 wrote: |
|
1. Refresh the page, that was Ammendment 1. |
Nope, it doesn't work for me in Firefox or IE. I'm clicking the text 'Total amount to insure', which is also a link, and all that happens is the help text toggles on and off. Focus doesn't shift to the text box so that I can change the amount.
| mike 2k:)2 wrote: |
| 2. Screen readers read all form elements regardless of display state. |
I did not know that.
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
Whoops,
Forgot to update the in-page example.
Give me a minute.
[edit]Done. [/edit]
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
| mike 2k:)2 wrote: |
|
The original question: What sense is generated by screen-readers when accessing a link inside a label? |
Modifying a short test page of my own:
http://www.gododdin.demon.co.uk/...
to include a link in a label (second form, 'town' field) I get the following results with HPR 3.04:
(a) In 'items' reading mode (the default) I see/hear the link and can select it to transfer control.
(b) In 'links' reading mode, I can 'tab' to it and select it to transfer control; it also appears in the 'list of links' if I ask for one.
However,
(c) In 'controls' reading mode, where the reader will only see forms control items, I can only see/hear 'HELP' as part of the label. Selecting it will simply open up a dialogue to fill in the Town field. i.e. it's not possible to select it as a link.
Other readers may/will work in different ways. If anyone has JAWS, WindowEyes, etc. it would be useful to hear what happens when those readers are used.
Any use?
.
Share:
Thanks Jake,
That does help, in that it confirms a & b methods are okay.
The difference you describe in c should not apply to my example as the help text is part of the label itself.
The reader should get the whole label including help text whether or not the link is actuated.
mike 2k:)2
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
Page 1 of 1
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum