WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Non Form Controls in Forms

for

Number of posts in this thread: 3 (In chronological order)

From: Brian Lovely
Date: Tue, Jun 16 2015 7:37AM
Subject: Non Form Controls in Forms
No previous message | Next message →

Is there anything that conflicts with accessibility in having buttons in a form that have nothing to do with the form? I feel like that muddies the semantic waters, but I can't quite decide just how.

Brian Lovely
= EMAIL ADDRESS REMOVED =

From: Brian Lovely
Date: Tue, Jun 16 2015 8:32AM
Subject: Re: Non Form Controls in Forms
← Previous message | Next message →

...specifically, this is a form containing filters for requesting a list of transactions that match the filter criteria. In addition to the button to post the form there are the resulting list, a link to trigger JS to print the list, a link to trigger JS to download the list, a link to reset the filters, a pagination link, aaaand, finally, links for triggering sorting behavior in the list. All of this inside the opening and closing form tags.



Brian Lovely
= EMAIL ADDRESS REMOVED =

> On Jun 16, 2015, at 9:37 AM, Brian Lovely < = EMAIL ADDRESS REMOVED = > wrote:
>
> Is there anything that conflicts with accessibility in having buttons in a form that have nothing to do with the form? I feel like that muddies the semantic waters, but I can't quite decide just how.
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
> > > >

From: _mallory
Date: Fri, Jun 26 2015 5:10AM
Subject: Re: Non Form Controls in Forms
← Previous message | No next message

This is my opinion of such things:
users nowadays are commonly confronted with "page scripts" with buttons
that Do Stuff with the contents of the page. Forms that actually submit
filled-in information, while sometimes replaced with loose HTML thingies
that make ajax calls, are still generally what they were several years ago.

It might make the most sense to have the actual form stuff be mostly
concerned with something the user will POST. Additional buttons with
listeners to scripts that adjust and change the page information (even
if the page information is inside a form) could just be kept outide
the form. If the user can change what's in the form with a button outside,
if nothing's stopping them from going back to the form itself and re-
POST-ing that info, then this should work.

Graphical styling might be more important here than usually, as you
would want it to be clear to all users that there's a form doing
the usual formy stuff, and there are separately buttons doing buttony
stuff... or somehow make it clear that they are only sending stuff to
a server when they hit a button called "save this stuff!" (or whatever).

I sometimes run into pages that don't have a clear "save stuff" button,
and they annoy the heck out of me, because it's not made clear that my
stuff was saved, or it's constantly saving and I feel like "but I'm not
done yet!!" (live collaborative editors maybe being the exception).

cheers,
_mallory

On Tue, Jun 16, 2015 at 10:32:46AM -0400, Brian Lovely wrote:
> ...specifically, this is a form containing filters for requesting a list of transactions that match the filter criteria. In addition to the button to post the form there are the resulting list, a link to trigger JS to print the list, a link to trigger JS to download the list, a link to reset the filters, a pagination link, aaaand, finally, links for triggering sorting behavior in the list. All of this inside the opening and closing form tags.
>
>
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
> > On Jun 16, 2015, at 9:37 AM, Brian Lovely < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Is there anything that conflicts with accessibility in having buttons in a form that have nothing to do with the form? I feel like that muddies the semantic waters, but I can't quite decide just how.
> >
> > Brian Lovely
> > = EMAIL ADDRESS REMOVED =
> > > > > > > > > > > >