E-mail List Archives
Thread: Forms, forms mode and static text interaction with Jaws.
Number of posts in this thread: 14 (In chronological order)
From: Ramya Sethuraman
Date: Fri, Oct 05 2012 4:12PM
Subject: Forms, forms mode and static text interaction with Jaws.
No previous message | Next message →
I am trying to solve a problem which I have come across so many times, I am
tempted to call it a pattern.
What is the best way to deal with free floating static text in the middle
of input fields in a form? This means,
it doesn't make sense to use aria-describedby to associate the free text
with any input field but at the same
time if the screen reader user is navigating the form by tabbing, it is
essential that he read that paragraph of text.
For eg, say you a form within a dialog with a bunch of fields and in
between have a Terms of Agreement section
with a big chunk of static text. How would you let Jaws know this a form
but there is also static text to be read?
Is it acceptable to just set a tabindex of 0 around the static text and
give it a hidden aria-label instructing Jaws
users to arrow down to read the text? How would they know to tab when the
section ends then? I feel like the
existing aria tags do not solve this problem.
Thoughts?
Thanks,
Ramya Sethuraman,
http://www.ramyasethuraman.com/
From: Léonie Watson
Date: Sat, Oct 06 2012 4:28AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
Ramya Sethuraman wrote:
"What is the best way to deal with free floating static text in the middle
of input fields in a form? This means, it doesn't make sense to use
aria-describedby to associate the free text with any input field but at the
same time if the screen reader user is navigating the form by tabbing, it is
essential that he read that paragraph of text."
It sounds as though the static text has relevance to completing the form, so
would aria-labelledby do the trick?
Léonie.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramya Sethuraman
Sent: 05 October 2012 23:13
To: WebAIM Discussion List
Subject: [WebAIM] Forms, forms mode and static text interaction with Jaws.
I am trying to solve a problem which I have come across so many times, I am
tempted to call it a pattern.
What is the best way to deal with free floating static text in the middle of
input fields in a form? This means, it doesn't make sense to use
aria-describedby to associate the free text with any input field but at the
same time if the screen reader user is navigating the form by tabbing, it is
essential that he read that paragraph of text.
For eg, say you a form within a dialog with a bunch of fields and in between
have a Terms of Agreement section with a big chunk of static text. How would
you let Jaws know this a form but there is also static text to be read?
Is it acceptable to just set a tabindex of 0 around the static text and give
it a hidden aria-label instructing Jaws users to arrow down to read the
text? How would they know to tab when the section ends then? I feel like the
existing aria tags do not solve this problem.
Thoughts?
Thanks,
Ramya Sethuraman,
http://www.ramyasethuraman.com/
messages to = EMAIL ADDRESS REMOVED =
From: Elle
Date: Sat, Oct 06 2012 12:06PM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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
From: Sailesh Panchang
Date: Mon, Oct 08 2012 7:02AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS 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
> > > >
From: Ramya Sethuraman
Date: Mon, Oct 08 2012 8:17AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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*
From: Elle
Date: Mon, Oct 08 2012 8:28AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
Ramya:
I would test several possible solutions with screen reader users (not
experts, average users) to see what their preferences are.
Thanks,
Elle
From: Sailesh Panchang
Date: Mon, Oct 08 2012 9:35AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
> > > >
From: Ramya Sethuraman
Date: Mon, Oct 08 2012 10:04AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
From: Birkir R. Gunnarsson
Date: Mon, Oct 08 2012 10:26AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
Just some thoughts.
If the text is entirely unrelated to the content of the form, it
sounds like it a. should not really be placed there in the first
place, and b. is not something the user necessarily needs to read in
order to complete the task (i.e. completing said form).
With that in mind I wonder how much you should need to go out of the
way in order to make sure the user reads that text. If it has
something, even vaguely, to do with a form field, I agree with
Salish's suggestion of using a check box or a radio button with a
refernce to a text and its location relative to that form control
(above, below). If not, would you really have to make sure the user
reads the text while filling in the form. May be just put a hidden
text (for instance, a heading) at the top of the form that says (this
form contains some textual info that cannot be read by screen readers
in forms mode, please keep this in mind), and then users have the
choice, just like everyone else, whether to read this text or not. As
it is not necessary to the actual completion of the form, it, to me at
least, sounds like a reasonable enough solution.
Again, this is just my opinion based on personal experience and on
teaching users to use their screen readers (not to many about 20 may
be), so do not take it as the ultimate solution or standard for how to
handle these things, rather as a perspective.
hth
-B
On 10/8/12, Ramya Sethuraman < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
> > > >
From: Sailesh Panchang
Date: Mon, Oct 08 2012 10:30AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
> > > >
From: Birkir R. Gunnarsson
Date: Mon, Oct 08 2012 10:41AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
>> >> >> >>
> > > >
From: Ramya Sethuraman
Date: Mon, Oct 08 2012 10:44AM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
Birkir,
Thanks, that helps. A checkbox or radio button is a visual design change and not really an option but the hidden text informing the user is certainly doable. Thanks again,
Ramya
Sent from my iPhone
On Oct 8, 2012, at 12:26 PM, "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = > wrote:
> Just some thoughts.
> If the text is entirely unrelated to the content of the form, it
> sounds like it a. should not really be placed there in the first
> place, and b. is not something the user necessarily needs to read in
> order to complete the task (i.e. completing said form).
> With that in mind I wonder how much you should need to go out of the
> way in order to make sure the user reads that text. If it has
> something, even vaguely, to do with a form field, I agree with
> Salish's suggestion of using a check box or a radio button with a
> refernce to a text and its location relative to that form control
> (above, below). If not, would you really have to make sure the user
> reads the text while filling in the form. May be just put a hidden
> text (for instance, a heading) at the top of the form that says (this
> form contains some textual info that cannot be read by screen readers
> in forms mode, please keep this in mind), and then users have the
> choice, just like everyone else, whether to read this text or not. As
> it is not necessary to the actual completion of the form, it, to me at
> least, sounds like a reasonable enough solution.
> Again, this is just my opinion based on personal experience and on
> teaching users to use their screen readers (not to many about 20 may
> be), so do not take it as the ultimate solution or standard for how to
> handle these things, rather as a perspective.
> hth
> -B
>
> On 10/8/12, Ramya Sethuraman < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
>> >> >> > > >
From: Tim Harshbarger
Date: Mon, Oct 08 2012 7:50PM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | Next message →
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 ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*
>> >> >> >>
> > > >
From: Ramya Sethuraman
Date: Mon, Oct 08 2012 9:43PM
Subject: Re: Forms, forms mode and static text interaction with Jaws.
← Previous message | No next message
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&servicesense&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 ADDRESS 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 ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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*