Greg and Steve, I had the idea of doing something like the following:
<!-- Begin Code --> Balance is within $<span style="position:relative;height:1%;padding-right:3em;margin:0;padding-left:0;"></span>credit limit<label for="balance" style="position:absolute;text-indent:-999em">Balance is within $</label><input id="balance" style="width:3em;position:relative;left:-8.25em;margin-right:-3em" name="balance" type="text" />More text here <!-- End Code --> Excuse the inline styling... And make sure that goes in a strict xhtml 1.0 document! or else you will go into quirks under IE. What that basically does is this: - Create the text which the input is to appear within. - Where you want the input, insert a 'spacer' (in this case, a span tag) that spaces out the text the same width that the input is - Create a label that is visible only to screen readers. This label should 'read right' i.e as if it is a label to an actual box - Create your input - Move the input back so that appears to be inside the gap made by the 'spacer' - remove the space (with negative-right margin = to width of input) Pros: -Visually, it kind of gives you what you want. Using em values means that increases of font sizes will still give the same result too. Cons: -We now have some extra text before/after the label/input pair, and it makes even less sense when being read back by a screen reader (or I would assume) - Because the em calculations are consistant over all browsers and font-sizes, sometimes the field overlaps the text. - BIG PITA: You will have to calculate a lot padding and negative margin values per input field!!!! Unknown: - How would this deal with big sentences going over multiple lines? - What if text appeared in a fluid layout and the wrap occurred before the input? Frankly, I think you would be better off ditching the label all together and hoping for the best with the text description mixed with inputs. Thanks for the exercise though, was fun! Karl On 5/15/07, Steve Green <[EMAIL PROTECTED]> wrote:
This kind of design always causes problems during user testing because a screen reader user does not know what comes after form controls when they occur in the middle of a line. In fact they don't even know it's in the middle of a line. You are asking them to read the whole sentence then go back to the middle to enter data in the form. Screen reader users' ability to deal with unusual constructions like this depends on their experience to a far greater extent than fully able users. We find that they may be able to hear all the content but just can't understand what they are supposed to do with it. If this form control is on its own then they will probably cope but if there are lots more like it then it becomes increasingly likely they won't. Blind people don't always 'visualise' things the way you might expect, particularly if they have been blind from birth. Invisible labels are fine, but if you really want it to be more accessible, put the form controls at the end of the sentences. Steve www.testpartners.co.uk www.accessibility.co.uk ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Sent: 14 May 2007 21:23 To: wsg@webstandardsgroup.org Subject: [WSG] Accessible, complex forms I have a dilemma that I hope someone can advise me on. A client wants a fairly complex form that will have input fields in the middle of a line of text (think "adlibs"), and then a select box at the end of the line. For example: [th] Alert ... [th] Status or delivery choice [td] Balance is within $_____ of my credit limit .... [td] select box [email/sms/both] I hope that example made sense. The problem we are facing is with screen readers, and our approach so far has been to create invisible labels with css. Is there a more accessible way to make this type of form more accessible? Thanks in advance, Greg ---------------- http://www.wolkinsphotography.com http://www.catscape.com ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******************************************************************* ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
