E-mail List Archives
Thread: Forms that delete something
Number of posts in this thread: 10 (In chronological order)
From: Laurence Hughes
Date: Mon, Jan 08 2024 1:49PM
Subject: Forms that delete something
No previous message | Next message →
Hi,
My companyâs web app is written in Ruby on Rails. As a developer, when you
want to let the user delete something (from the database), a common
approach is to use the Rails `button_toâ method. As a developer you pass
into this method some text for a button and a URL for a server resource
which will handle deleting the data. In terms of rendered HTML, the method
generates a form set to use the POST method and to submit to the URL you
provided. The form includes a button of type âsubmitâ and no other form
elements except a hidden input which tells Rails to perform an HTTP DELETE
rather than a POST.
As a sighted user, all I see is a button.
I see some benefits to this pattern. Developers have, for a long time,
misused links (with the help of JavaScript) to enable deletion, and this
isnât good. As we know, links are for a different purpose, and using a link
for an unintended purpose breaks user expectations.
But while Iâm sure that a link is the wrong tool for the job of deleting
something from a database, Iâm also not 100% sure whether a form, that only
includes a single element (a button), is the right interface to present.
The user isnât really âinputtingâ anything, either to add, edit or search,
so is a form OK here?
Would this feel weird to a screen reader user? A form with no other
elements except a button that says âDelete xyzâ? Or am I being silly and
this is perfectly normal, and is the expected/conventional way to provide a
âDelete xyzâ interface accessibly?
Thanks in advance for any advice!
Laurence
From: Dean.Vasile@outlook.com
Date: Mon, Jan 08 2024 1:54PM
Subject: Re: Forms that delete something
← Previous message | Next message →
Using a form with just a button for deletion is a common and accessible approach. Screen reader users are accustomed to interacting with forms for various actions, including deletion. It helps maintain consistency and aligns with web accessibility standards.
Dean Vasile
617-799-1162
> On Jan 8, 2024, at 3:49â¯PM, Laurence Hughes < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi,
>
> My companyâs web app is written in Ruby on Rails. As a developer, when you
> want to let the user delete something (from the database), a common
> approach is to use the Rails `button_toâ method. As a developer you pass
> into this method some text for a button and a URL for a server resource
> which will handle deleting the data. In terms of rendered HTML, the method
> generates a form set to use the POST method and to submit to the URL you
> provided. The form includes a button of type âsubmitâ and no other form
> elements except a hidden input which tells Rails to perform an HTTP DELETE
> rather than a POST.
>
> As a sighted user, all I see is a button.
>
> I see some benefits to this pattern. Developers have, for a long time,
> misused links (with the help of JavaScript) to enable deletion, and this
> isnât good. As we know, links are for a different purpose, and using a link
> for an unintended purpose breaks user expectations.
>
> But while Iâm sure that a link is the wrong tool for the job of deleting
> something from a database, Iâm also not 100% sure whether a form, that only
> includes a single element (a button), is the right interface to present.
> The user isnât really âinputtingâ anything, either to add, edit or search,
> so is a form OK here?
>
> Would this feel weird to a screen reader user? A form with no other
> elements except a button that says âDelete xyzâ? Or am I being silly and
> this is perfectly normal, and is the expected/conventional way to provide a
> âDelete xyzâ interface accessibly?
>
> Thanks in advance for any advice!
> Laurence
From: Jeremy Echols
Date: Mon, Jan 08 2024 3:47PM
Subject: Re: Forms that delete something
← Previous message | Next message →
Agreed - the HTML "form" may feel like it's incorrect because the name "form" sort of suggests to our collective conscious something with lots of blank spaces that needs information. But it is indeed the right element to use for deletion.
Think of it as a pre-filled paper form where all you have to do is submit it to the right person / organization in order to, say, start a free trial of Sirius XM or something. All the necessary data was pre-printed onto that form because they want it to be easy, so all you have to do is submit it. Same concept with the button-only form: it's been "pre-filled" with the hidden values (such as the request to delete a record). And the action itself, which holds the destination URL, is also just pre-filled data telling the form what it's for and likely the database ID of the record to delete.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, January 8, 2024 12:54
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Forms that delete something
Using a form with just a button for deletion is a common and accessible approach. Screen reader users are accustomed to interacting with forms for various actions, including deletion. It helps maintain consistency and aligns with web accessibility standards.
Dean Vasile
617-799-1162
> On Jan 8, 2024, at 3:49â¯PM, Laurence Hughes < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi,
>
> My companyâs web app is written in Ruby on Rails. As a developer, when
> you want to let the user delete something (from the database), a
> common approach is to use the Rails `button_toâ method. As a developer
> you pass into this method some text for a button and a URL for a
> server resource which will handle deleting the data. In terms of
> rendered HTML, the method generates a form set to use the POST method
> and to submit to the URL you provided. The form includes a button of
> type âsubmitâ and no other form elements except a hidden input which
> tells Rails to perform an HTTP DELETE rather than a POST.
>
> As a sighted user, all I see is a button.
>
> I see some benefits to this pattern. Developers have, for a long time,
> misused links (with the help of JavaScript) to enable deletion, and
> this isnât good. As we know, links are for a different purpose, and
> using a link for an unintended purpose breaks user expectations.
>
> But while Iâm sure that a link is the wrong tool for the job of
> deleting something from a database, Iâm also not 100% sure whether a
> form, that only includes a single element (a button), is the right interface to present.
> The user isnât really âinputtingâ anything, either to add, edit or
> search, so is a form OK here?
>
> Would this feel weird to a screen reader user? A form with no other
> elements except a button that says âDelete xyzâ? Or am I being silly
> and this is perfectly normal, and is the expected/conventional way to
> provide a âDelete xyzâ interface accessibly?
>
> Thanks in advance for any advice!
> Laurence
From: tim.harshbarger@deque.com
Date: Tue, Jan 09 2024 7:24AM
Subject: Re: Forms that delete something
← Previous message | Next message →
Realistically, whether or not the button is inside a form will be meaningful to someone using a screen reader. Unless you do something special, the person using a screen reader most likely will not be informed that the button is contained inside a form. However, what is important for people using screen readers is that the element conveys its role (that it is a button) and its name (that its label is delete).
There can be some keyboard advantages to using a form with a submit button. If a button is type="submit", it becomes the default action of the form which means that pressing enter on some other types of controls (like a text field) will activate that submit function without the person needing to tab to the submit button.
Regarding links vs. buttons, I expect those of us who are very focused on the design and development of user interfaces place way more emphasis on this than the people who use the user interfaces.
For example, you have a multi-page form with a next page and previous page function. Technically, if pressing next loads a whole new page it should be a link. If it is a Single Page App (SPA) which only updates some of the content on the page, it should be a button. For people who don't spend their days focused on this type of detail that is a meaningless difference.
It is most definitely advisable to try to use some kind of rule of thumb about links and buttons. It is probably more important that you are consistent within your interface than you try to apply the rule universally when it will have no meaning for non-technical users.
Hope this helps.
Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Laurence Hughes
Sent: Monday, January 8, 2024 2:50 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Forms that delete something
Hi,
My companyâs web app is written in Ruby on Rails. As a developer, when you want to let the user delete something (from the database), a common approach is to use the Rails `button_toâ method. As a developer you pass into this method some text for a button and a URL for a server resource which will handle deleting the data. In terms of rendered HTML, the method generates a form set to use the POST method and to submit to the URL you provided. The form includes a button of type âsubmitâ and no other form elements except a hidden input which tells Rails to perform an HTTP DELETE rather than a POST.
As a sighted user, all I see is a button.
I see some benefits to this pattern. Developers have, for a long time, misused links (with the help of JavaScript) to enable deletion, and this isnât good. As we know, links are for a different purpose, and using a link for an unintended purpose breaks user expectations.
But while Iâm sure that a link is the wrong tool for the job of deleting something from a database, Iâm also not 100% sure whether a form, that only includes a single element (a button), is the right interface to present.
The user isnât really âinputtingâ anything, either to add, edit or search, so is a form OK here?
Would this feel weird to a screen reader user? A form with no other elements except a button that says âDelete xyzâ? Or am I being silly and this is perfectly normal, and is the expected/conventional way to provide a âDelete xyzâ interface accessibly?
Thanks in advance for any advice!
Laurence
From: David Farough
Date: Tue, Jan 09 2024 7:49AM
Subject: Re: Forms that delete something
← Previous message | Next message →
In a scenario like this, where should focus go after the delete is performed
Should focus remain on the button?
Maybe this is something for the designer to consider.
Perhaps a status message should be provided.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Tuesday, January 9, 2024 9:25 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Forms that delete something
Realistically, whether or not the button is inside a form will be meaningful to someone using a screen reader. Unless you do something special, the person using a screen reader most likely will not be informed that the button is contained inside a form. However, what is important for people using screen readers is that the element conveys its role (that it is a button) and its name (that its label is delete).
There can be some keyboard advantages to using a form with a submit button. If a button is type="submit", it becomes the default action of the form which means that pressing enter on some other types of controls (like a text field) will activate that submit function without the person needing to tab to the submit button.
Regarding links vs. buttons, I expect those of us who are very focused on the design and development of user interfaces place way more emphasis on this than the people who use the user interfaces.
For example, you have a multi-page form with a next page and previous page function. Technically, if pressing next loads a whole new page it should be a link. If it is a Single Page App (SPA) which only updates some of the content on the page, it should be a button. For people who don't spend their days focused on this type of detail that is a meaningless difference.
It is most definitely advisable to try to use some kind of rule of thumb about links and buttons. It is probably more important that you are consistent within your interface than you try to apply the rule universally when it will have no meaning for non-technical users.
Hope this helps.
Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Laurence Hughes
Sent: Monday, January 8, 2024 2:50 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Forms that delete something
Hi,
My company's web app is written in Ruby on Rails. As a developer, when you want to let the user delete something (from the database), a common approach is to use the Rails `button_to' method. As a developer you pass into this method some text for a button and a URL for a server resource which will handle deleting the data. In terms of rendered HTML, the method generates a form set to use the POST method and to submit to the URL you provided. The form includes a button of type 'submit' and no other form elements except a hidden input which tells Rails to perform an HTTP DELETE rather than a POST.
As a sighted user, all I see is a button.
I see some benefits to this pattern. Developers have, for a long time, misused links (with the help of JavaScript) to enable deletion, and this isn't good. As we know, links are for a different purpose, and using a link for an unintended purpose breaks user expectations.
But while I'm sure that a link is the wrong tool for the job of deleting something from a database, I'm also not 100% sure whether a form, that only includes a single element (a button), is the right interface to present.
The user isn't really "inputting" anything, either to add, edit or search, so is a form OK here?
Would this feel weird to a screen reader user? A form with no other elements except a button that says "Delete xyz"? Or am I being silly and this is perfectly normal, and is the expected/conventional way to provide a "Delete xyz" interface accessibly?
Thanks in advance for any advice!
Laurence
From: Chase, DJ
Date: Tue, Jan 09 2024 8:19AM
Subject: Re: Forms that delete something
← Previous message | Next message →
Habitually using forms for this also allows you to be consistent if you occasionally want to ask for conformation --- all you need to do is just include a required checkbox in the form to confirm.
Cheers,
--
DJ Chase
Digital Accessibility Specialist, NECC
They, Them, Theirs
+1 978 556 3794
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Jeremy Echols < = EMAIL ADDRESS REMOVED = >
Sent: Monday, January 8, 2024 17:47
To: WebAIM Discussion List
Subject: Re: [WebAIM] Forms that delete something
[You don't often get email from = EMAIL ADDRESS REMOVED = . Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
ATTENTION: This email is from an external source. Do Not click on any links or open any attachments unless you recognize the sender and know the content is safe. To report a suspicious email, please use the new phishing alert button in outlook
Agreed - the HTML "form" may feel like it's incorrect because the name "form" sort of suggests to our collective conscious something with lots of blank spaces that needs information. But it is indeed the right element to use for deletion.
Think of it as a pre-filled paper form where all you have to do is submit it to the right person / organization in order to, say, start a free trial of Sirius XM or something. All the necessary data was pre-printed onto that form because they want it to be easy, so all you have to do is submit it. Same concept with the button-only form: it's been "pre-filled" with the hidden values (such as the request to delete a record). And the action itself, which holds the destination URL, is also just pre-filled data telling the form what it's for and likely the database ID of the record to delete.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, January 8, 2024 12:54
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Forms that delete something
Using a form with just a button for deletion is a common and accessible approach. Screen reader users are accustomed to interacting with forms for various actions, including deletion. It helps maintain consistency and aligns with web accessibility standards.
Dean Vasile
617-799-1162
> On Jan 8, 2024, at 3:49â¯PM, Laurence Hughes < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi,
>
> My companyâs web app is written in Ruby on Rails. As a developer, when
> you want to let the user delete something (from the database), a
> common approach is to use the Rails `button_toâ method. As a developer
> you pass into this method some text for a button and a URL for a
> server resource which will handle deleting the data. In terms of
> rendered HTML, the method generates a form set to use the POST method
> and to submit to the URL you provided. The form includes a button of
> type âsubmitâ and no other form elements except a hidden input which
> tells Rails to perform an HTTP DELETE rather than a POST.
>
> As a sighted user, all I see is a button.
>
> I see some benefits to this pattern. Developers have, for a long time,
> misused links (with the help of JavaScript) to enable deletion, and
> this isnât good. As we know, links are for a different purpose, and
> using a link for an unintended purpose breaks user expectations.
>
> But while Iâm sure that a link is the wrong tool for the job of
> deleting something from a database, Iâm also not 100% sure whether a
> form, that only includes a single element (a button), is the right interface to present.
> The user isnât really âinputtingâ anything, either to add, edit or
> search, so is a form OK here?
>
> Would this feel weird to a screen reader user? A form with no other
> elements except a button that says âDelete xyzâ? Or am I being silly
> and this is perfectly normal, and is the expected/conventional way to
> provide a âDelete xyzâ interface accessibly?
>
> Thanks in advance for any advice!
> Laurence
From: tim.harshbarger@deque.com
Date: Tue, Jan 09 2024 10:23AM
Subject: Re: Forms that delete something
← Previous message | Next message →
You want to maintain the focus wherever it seems to make best sense for users.
If the delete button disappears, you want to move focus to whatever other element seems to make sense.
If the delete button is still present, one option might be to ensure focus returns to that delete button or remains on it.
If you display some kind of message about the delete being successful or failing, you definitely want to ensure a person using a screen reader knows about it. If you are maintaining the focus on the delete button or moving it to another interactive element, then it would be a good situation to use a live region to ensure the message is spoken.
That was a very inciteful question to ask!
Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of David Farough
Sent: Tuesday, January 9, 2024 8:50 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Forms that delete something
In a scenario like this, where should focus go after the delete is performed Should focus remain on the button?
Maybe this is something for the designer to consider.
Perhaps a status message should be provided.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Tuesday, January 9, 2024 9:25 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Forms that delete something
Realistically, whether or not the button is inside a form will be meaningful to someone using a screen reader. Unless you do something special, the person using a screen reader most likely will not be informed that the button is contained inside a form. However, what is important for people using screen readers is that the element conveys its role (that it is a button) and its name (that its label is delete).
There can be some keyboard advantages to using a form with a submit button. If a button is type="submit", it becomes the default action of the form which means that pressing enter on some other types of controls (like a text field) will activate that submit function without the person needing to tab to the submit button.
Regarding links vs. buttons, I expect those of us who are very focused on the design and development of user interfaces place way more emphasis on this than the people who use the user interfaces.
For example, you have a multi-page form with a next page and previous page function. Technically, if pressing next loads a whole new page it should be a link. If it is a Single Page App (SPA) which only updates some of the content on the page, it should be a button. For people who don't spend their days focused on this type of detail that is a meaningless difference.
It is most definitely advisable to try to use some kind of rule of thumb about links and buttons. It is probably more important that you are consistent within your interface than you try to apply the rule universally when it will have no meaning for non-technical users.
Hope this helps.
Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Laurence Hughes
Sent: Monday, January 8, 2024 2:50 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Forms that delete something
Hi,
My company's web app is written in Ruby on Rails. As a developer, when you want to let the user delete something (from the database), a common approach is to use the Rails `button_to' method. As a developer you pass into this method some text for a button and a URL for a server resource which will handle deleting the data. In terms of rendered HTML, the method generates a form set to use the POST method and to submit to the URL you provided. The form includes a button of type 'submit' and no other form elements except a hidden input which tells Rails to perform an HTTP DELETE rather than a POST.
As a sighted user, all I see is a button.
I see some benefits to this pattern. Developers have, for a long time, misused links (with the help of JavaScript) to enable deletion, and this isn't good. As we know, links are for a different purpose, and using a link for an unintended purpose breaks user expectations.
But while I'm sure that a link is the wrong tool for the job of deleting something from a database, I'm also not 100% sure whether a form, that only includes a single element (a button), is the right interface to present.
The user isn't really "inputting" anything, either to add, edit or search, so is a form OK here?
Would this feel weird to a screen reader user? A form with no other elements except a button that says "Delete xyz"? Or am I being silly and this is perfectly normal, and is the expected/conventional way to provide a "Delete xyz" interface accessibly?
Thanks in advance for any advice!
Laurence
From: Peter Weil
Date: Tue, Jan 09 2024 4:24PM
Subject: Re: Forms that delete something
← Previous message | Next message →
Tim,
Did you mean to say that "whether or not the button is inside a form will **not** be meaningful to someone using a screen readerâ?
Otherwise, I find these two sentences confusing:
> Realistically, whether or not the button is inside a form will be meaningful to someone using a screen reader. Unless you do something special, the person using a screen reader most likely will not be informed that the button is contained inside a form.
Iâm still not entirely persuaded (yet) that it is necessarily better or more helpful to place the button inside a form. And is this just for deletions? What about patches that, say, remove or change a relationship in the database?
Thanks,
Peter
--
Peter Weil
Web Developer
University Marketing Web Services
Office of Strategic Communications
University of WisconsinâMadison
608-220-3089
From: tim.harshbarger@deque.com
Date: Wed, Jan 10 2024 6:25AM
Subject: Re: Forms that delete something
← Previous message | Next message →
Yes, that is correct. That is what I meant to write.
A screen reader will not tell a user if a form control is nested inside a form element.
If someone does think it is important the screen reader user know that form controls are part of a form, then there are techniques that can be used to do that. However, just nesting controls inside a form element will not do that.
The crucial aspects of the technique that was originally mentioned are:
* It is possible to tab to the button and activate it with a keyboard.
* The button conveys its role.
* The button conveys an accessible name.
It sounds like the technique did all of that. One additional consideration might be if there are multiple delete buttons on the same page. In that case, you might want to include additional information so it is more obvious to a screen reader user what the delete button will delete.
If there is some kind of confirmation message for the delete action, you will also want to ensure there is some way screen reader users are informed of that status.
Again, there are other reasons why someone would use a form element to contain all the controls for a form, but none of those reasons involve it somehow automatically informing screen reader users of that information.
I apologize for the lack of clarity on the last response. I hope this helps.
Thanks!
Tim
-----Original Message-----
From: Peter Weil < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, January 9, 2024 5:25 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Tim Harshbarger < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Forms that delete something
Tim,
Did you mean to say that "whether or not the button is inside a form will **not** be meaningful to someone using a screen readerâ?
Otherwise, I find these two sentences confusing:
> Realistically, whether or not the button is inside a form will be meaningful to someone using a screen reader. Unless you do something special, the person using a screen reader most likely will not be informed that the button is contained inside a form.
Iâm still not entirely persuaded (yet) that it is necessarily better or more helpful to place the button inside a form. And is this just for deletions? What about patches that, say, remove or change a relationship in the database?
Thanks,
Peter
--
Peter Weil
Web Developer
University Marketing Web Services
Office of Strategic Communications
University of WisconsinâMadison
608-220-3089
From: Peter Weil
Date: Wed, Jan 10 2024 7:33AM
Subject: Re: Forms that delete something
← Previous message | No next message
Thanks for clarifying this, Tim.
I donât think thereâs any question that using a button, using the technique described below, is the way to go for making a one-off change to a database. Using a form for this seems perfectly fine, but perhaps not always necessary. If you have a page with multiple delete (and perhaps other) buttons on a page, embedding each button within a form could get a little onerous, especially if there is little or no clear advantage to doing so.
Inertia.js, for example, provides a REST API that enables you to make make DELETE, PATCH, etc. requests without using a form. This can be very useful and convenient, as long as you make the buttons accessible.
Peter
> On Jan 10, 2024, at 7:25 AM, = EMAIL ADDRESS REMOVED = wrote:
>
> Yes, that is correct. That is what I meant to write.
>
> A screen reader will not tell a user if a form control is nested inside a form element.
>
> If someone does think it is important the screen reader user know that form controls are part of a form, then there are techniques that can be used to do that. However, just nesting controls inside a form element will not do that.
>
> The crucial aspects of the technique that was originally mentioned are:
>
> * It is possible to tab to the button and activate it with a keyboard.
> * The button conveys its role.
> * The button conveys an accessible name.
>
> It sounds like the technique did all of that. One additional consideration might be if there are multiple delete buttons on the same page. In that case, you might want to include additional information so it is more obvious to a screen reader user what the delete button will delete.
>
> If there is some kind of confirmation message for the delete action, you will also want to ensure there is some way screen reader users are informed of that status.
>
> Again, there are other reasons why someone would use a form element to contain all the controls for a form, but none of those reasons involve it somehow automatically informing screen reader users of that information.
>
> I apologize for the lack of clarity on the last response. I hope this helps.
>
> Thanks!
> Tim
> -----Original Message-----
> From: Peter Weil < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, January 9, 2024 5:25 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Tim Harshbarger < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Forms that delete something
>
> Tim,
>
> Did you mean to say that "whether or not the button is inside a form will **not** be meaningful to someone using a screen readerâ?
>
> Otherwise, I find these two sentences confusing:
>
>> Realistically, whether or not the button is inside a form will be meaningful to someone using a screen reader. Unless you do something special, the person using a screen reader most likely will not be informed that the button is contained inside a form.
>
> Iâm still not entirely persuaded (yet) that it is necessarily better or more helpful to place the button inside a form. And is this just for deletions? What about patches that, say, remove or change a relationship in the database?
>
> Thanks,
>
> Peter
>
> --
> Peter Weil
> Web Developer
> University Marketing Web Services
> Office of Strategic Communications
> University of WisconsinâMadison
> 608-220-3089
>
>
>