E-mail List Archives
Re: Forms, forms mode and static text interaction with Jaws.
From: Sailesh Panchang
Date: Oct 8, 2012 10:30AM
- Next message: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- Previous message: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- Next message in Thread: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- View all messages in this Thread
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*
> > > >
- Next message: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- Previous message: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- Next message in Thread: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Forms, forms mode and static text interaction with Jaws."
- View all messages in this Thread