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:26AM

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