WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Forms, forms mode and static text interaction with Jaws.

for

From: Ramya Sethuraman
Date: Oct 8, 2012 9:43PM

Hey Tim

Thanks for the suggestions. An example of what I am talking about can be
seen when we try to create a Google account for Google adsense, the page
starts off with the text below which is followed by text input fields for
email address and password that the user has to fill. This is followed by a
few lines of text and then a text input field to fill in the captcha
information. I guess what I need to understand better is what is the most
likely way a screen reader user will navigate a dialog which has a few form
fields with text below like I have shown. If they are navigating using
regular down arrow in virtual pc cursor mode, it is less of a concern. But,
if typically they would tab from one field to another when they hear Jaws
switch to forms mode, then this text might be lost. There are some good
suggestions in this thread however to try to prevent that: visual design
change to have a checkbox to ensure users have read the text, hidden text
for screen reader users informing them about the static text, marking the
text as a complementary landmark etc...

Google AdSense: Create a Google AccountTo use Google AdSense with a new
Google Account, please start by filling out the form below. With your email
address and chosen password, you can access Google AdSense and many other
Google services. Learn More <http://www.google.com/help/faq_accounts.html>;

*Do you already use Gmail, , Web History, , or Product Search?*
If so, you already have a Google Account. Sign in with your existing
account<https://accounts.google.com/Login?continue=https%3A%2F%2Fwww.google.com%2Fadsense%2Fv3%2Fascheck%3Fhl%3Den%26sourceid%3Daso%26subid%3Dus-en-et-nelson_adshp_bt%26utm_content%3Dnsufv1%26gsessionid%3DWgXTfyfyS2wj3IXg2473-Q%26pli%3D1%26auth%3DDQAAAHoAAAC2jaG4td1LeRWCW9_s47m8g1AEXYppGaas_eiwtYLOz1DPa7cwBw9-Z5xK_5nH1aGVmkLGpOSzkqVlWDwQX9czqa2VXTJCP7MIbYpaLQkcwePd0NW2MrCYoYvFmPdHQbWSEKlnQMqxKOpzH4-XaW6BK_tMXNPzWxdM__rGF16x7Q&hl=en_US&service­sense&skipvpage=true>
to
use Google AdSense.

----form fields show up here-----

Thanks,
Ramya


On Mon, Oct 8, 2012 at 9:50 PM, Tim Harshbarger <
<EMAIL REMOVED> > wrote:

> This discussion seems to be focusing on how to ensure someone using a
> screen reader reads extraneous text that isn't part of a form field when
> the text is displayed as part of a form.
>
> It occurs to me that there really isn't a way to ensure someone who can
> read the page will read that text either. You can do things to try to draw
> attention to the text, but you can't ensure the user reads it. The screen
> reader problem you are trying to solve may be a lot easier to solve if you
> make it parallel the visual issue--which really is "How do you increase the
> likelihood that the person will read the advertisement or extraneous text?"
>
> I think someone mentioned using a complementary role to the text. A
> header may also be a way to draw attention to the text. It is a solution
> with its own drawbacks, but if your intention is to draw the user's focus
> to that text, you basically need to add something that is likely to catch
> the attention of someone using a screen reader. If you want to reduce
> confusion about whether or not the text relates to the form, you will
> probably need to add some things to ensure the user knows this is an
> advertisement.
>
> But all the above are just thoughts off the top of my head and are totally
> unedited.
>
> Thanks,
> Tim
>
> -----Original Message-----
> From: <EMAIL REMOVED> [mailto:
> <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
> Sent: Monday, October 08, 2012 11:42 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Forms, forms mode and static text interaction with
> Jaws.
>
> Salish
>
> Good point. In fact I generally do not recomend people tab directly
> through a form in form's mode. I tell the users that I teach to use
> the arrow keys to read all fields and labels, and then use enter key
> to switch into and out of forms mode for the fields, or to use "e" to
> jump between edit fields. I find, generally, that filling out a form
> using tab only is only a good/acceptable solution for user/pass
> fields, but I never recommend it outside of that scenario.
>
>
> On 10/8/12, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> > Tabbing through a page is not the only way a user reviews a page and
> > all its sections / content.
> > There is no requirement that that content should be accessed only
> > while filling out the form, is there?
> > Should the user be prevented from getting to that content if he does
> > not attempt to fill the form?
> > I did suggest two methods that will aid discoverability and navigability.
> > Regards,
> > Sailesh
> >
> >
> > On 10/8/12, Ramya Sethuraman < <EMAIL REMOVED> > wrote:
> >> Thanks Sailesh. The thing is, I have come across designs where there is
> >> unrelated textual content between form
> >> fields. It might be promotions, it might be terms, basically it could be
> >> a
> >> paragraph saying anything not much related
> >> to any of the fields. I like the role=complementary idea but if a user
> is
> >> in forms mode navigating by tabbing through
> >> the fields, won't he miss this static text content?
> >>
> >> For eg: imagine a form within a dialog like this (pseudo code):
> >>
> >> <form>
> >> first name: <input field>
> >> last name: <input field>
> >> i am some random text not related to first name or last name or address
> >> fields.
> >> address: <addr field>
> >> i am some more random text floating here within the form
> >> </form>
> >>
> >> How do you make sure a jaws user in forms mode navigating by tabbing
> >> through the fields in this form reads the 2 paragraphs of static text?
> >>
> >> Thanks for the prompt response,
> >>
> >> Ramya
> >>
> >>
> >> On Mon, Oct 8, 2012 at 11:35 AM, Sailesh Panchang <
> >> <EMAIL REMOVED> > wrote:
> >>
> >>> Ramya,
> >>> My previous response never suggested you associate the entire
> >>> paragraph via aria-describedby. In fact it was to the contrary.
> >>> Secondly, the suggestion was associate the words "Please read terms"
> >>> with the closest / related field.
> >>> The solution is always with reference to the context and now in your
> >>> latest message you mention promotional content unrelated to the form
> >>> being placed between form controls.
> >>> SoI'd suggest something different here.
> >>> Consider using role="complementary" maybe with aria-label="(Current
> >>> promotions)". Again it does not have to be tab-navigable.
> >>> Maybe with HTML5, the 'aside' tag may work.
> >>> Also if the paragraph has a heading or an image with text that might
> >>> work like a heading, use an h<n> tag.
> >>> Rightho,
> >>> Sailesh
> >>>
> >>>
> >>> On 10/8/12, Ramya Sethuraman < <EMAIL REMOVED> > wrote:
> >>> > Hey Sailesh
> >>> >
> >>> > Thanks. I can add the aria-describedby as you suggested except that
> it
> >>> > is
> >>> > no an ideal solution:
> >>> >
> >>> > 1. I am associating text with a field when the paragraph has nothing
> >>> > to
> >>> do
> >>> > with the field. For eg: say the fields are first name, last name and
> >>> > address and the text is, 'We also have a new offer blah blah'.
> >>> >
> >>> > 2. aria-describedby will force the screen reader to announce the
> >>> > entire
> >>> > paragraph of text unless the user decides to stop the screen reader
> >>> > from
> >>> > announcing it.
> >>> >
> >>> > It seems to me like there is no clearly defined way to support this
> >>> > forms/non-forms mode currently with screen readers. Also, this is
> >>> > turning
> >>> > out to be a fairly common use case. So, it's not feasible to tell
> >>> designers
> >>> > to only have focusable, interactable elements in a form within a
> >>> > dialog.
> >>> >
> >>> > I guess, for now, we make do with what we have?
> >>> >
> >>> > Many thanks for your response,
> >>> >
> >>> > Ramya
> >>> > Facebook Accessibility.
> >>> >
> >>> >
> >>> > On Mon, Oct 8, 2012 at 9:02 AM, Sailesh Panchang
> >>> > < <EMAIL REMOVED>
> >>> >> wrote:
> >>> >
> >>> >> Ramya,
> >>> >> Not every piece of info in a form needs to be tab-navigable.
> >>> >> Aria-describedby is alright for shorter Text such as data format
> >>> >> tips,
> >>> >> error messages that may be visible at all times or are displayed
> when
> >>> >> the form control receives focus.
> >>> >>
> >>> >> Making a paragraph of text tab-navigable will make the text read
> out
> >>> >> as a chunk ... not the best experience for users. Most users may
> >>> >> prefer to read through the text separately.
> >>> >> So one option is to place a checkbox:
> >>> >> "I have read and agree to the terms below".
> >>> >> If this is not possible, then place visible / off-screen text to the
> >>> >> closest / related field, like 'Please read terms below / above);
> and
> >>> >> associate it with aria-describedby.
> >>> >> Sailesh Panchang
> >>> >>
> >>> >>
> >>> >> On 10/6/12, Elle < <EMAIL REMOVED> > wrote:
> >>> >> > I don't know how people feel about the semantic nature of this
> >>> >> suggestion,
> >>> >> > but we have made some critical disclaimer information tab
> focusable
> >>> >> > in
> >>> >> our
> >>> >> > forms before to ensure that the information was not missed, even
> >>> >> > with
> >>> >> older
> >>> >> > screen readers, when navigating a form by tabbing.
> >>> >> >
> >>> >> >
> >>> >> > Cheers,
> >>> >> > Elle
> >>> >> > > >>> >> > > >>> >> > > >>> >> >
> >>> >> > >>> >> > >>> >> > >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > *I also exist @: http://www.ramyasethuraman.com*
> >>> > > >>> > > >>> > > >>> >
> >>> > >>> > >>> > >>>
> >>
> >>
> >>
> >> --
> >> *I also exist @: http://www.ramyasethuraman.com*
> >> > >> > >> > >>
> > > > > > > >
> > > > > > >



--
*I also exist @: http://www.ramyasethuraman.com*