WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: Oct 8, 2012 10:41AM

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*
>> >> >> >>
> > > >