Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED]
I don't think that pressing enter to submit is an accessibility issue at all, it's simply expected behaviour. If people are used to being able to do that in their browser then it should not be forced or suppressed in any way. Keyboard only users is an interesting one... so if the person is a keyboard user out of choice (as in they prefer to use the keyboard for ease of use) they might well be using a setup where it's not possible to highlight the submit button to submit it. Someone who is using the keyboard only because they have difficulty with a mouse is unlikely to have that problem as they'd choose a setup which allows them to do that. As for putting line breaks in the field, as far as I know no browsers will submit a form when you press enter on a textarea, and as input type=field /'s are only one line, they surely wouldn't expect to be able to put a line break there anyway. I actually publish a blog post on a very similar topic (although not so focussed on the accessibility side of things) yesterday: http://www.norestfortheweekend.com/2009/10/20/on-forms-submit-buttons-and-browsers/ I hope you find it interesting! Mark On 21 Oct 2009, at 04:39, Chris Vickery wrote: Thanks Jason, In this case it’s for an input field, not a textarea, and enter will still not submit (unless you tab out) so in this case makes it contrary to ‘native browser behaviour’. Essentially our input fields would, (although they identify themselves as input fields) would behave like textareas, without line breaks. I’m not really familiar with using a text to speech reader, but that sounds messy to me. Interestingly the source itself looks pretty straight forward: div id=abc-form class=form form name=abcform id=abcform method=post action= input type=text name=abcform[email1] value= id=email1 class=text /input type=submit name=form[subscribebutton1] value=Subscribe id=subscribebutton1 / /form /div There must be something buried in the styling causing this behaviour. Chris From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of ja...@flexewebs.com Sent: Wednesday, 21 October 2009 11:03 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED] Hi Chris, The submission by pressing enter is a native browser behaviour, hence is not an accessibility issue. You will only be able to submit via enter from an input field and not from a textarea, which you have to tab out of and then hit enter. So I doubt you will find any references to back-up your claim. If you do, send it through so we can debunk it. :-D Best, Jason Sent from my BlackBerry® wireless device From: Chris Vickery chris.vick...@privacy.gov.au Date: Wed, 21 Oct 2009 10:20:51 +1100 To: wsg@webstandardsgroup.orgwsg@webstandardsgroup.org Subject: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED] We’re accessibility testing at the moment. We’ve got some email forms (ie. Put in your email address to subscribe - submit) that do not currently submit if you press enter. Personally I feel this should be an accessibility issue, but I am finding it difficult to locate any solid documentation to back up my claim. I’ve had the argument put to me that a keyboard only user could still tab to the submit button, then press enter, but this seems very unintuitive to me to force users to do this. I’ve also had put to me that some users get confused if they want to put line breaks in a field and submit by accident... and so to be consistent pressing enter should never submit a form. (data entry people would love that one :P) Is submitting by pressing enter from a form best practice, or just common practice? Is it an accessibility problem? ... and to what degree? *** WARNING: The information contained in this email may be confidential. If you are not the intended recipient, any use or copying of any part of this information is unauthorised. If you have received this email in error, we apologise for any inconvenience and request that you notify the sender immediately and delete all copies of this email, together with any attachments. *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org
Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED]
Sorry Mark but I'm going to have to counter that argument because I believe it *is* in part an accessibility issue, particularly relating to screen readers which as we know linearly parse a page ... so unless there is instructional text or help before the text field advising them of how to activate or submit that form field or if the behaviour is inconsistent with both web and on-site conventions then the possible data loss, accidental data submission or lack of any response on pressing Enter because that user isn't aware of what is going to happen or not happen (until deciding after a delay that the Enter key did nothing) until they try it. The standard browser convention is that in an input field (not textarea), pressing Enter will activate the action of the containing form element (if it has one, or unless it's an ASP.NET app in which case the form element envelops the entire page). Speaking of which, does ASP.NET 3.5 handle that differently? Nathanael Boehm http://www.purecaffeine.com/about/ Canberra, Australia 0409 288 464 On Wed, Oct 21, 2009 at 6:26 PM, Mark Stickley markstick...@theyakshack.co.uk wrote: I don't think that pressing enter to submit is an accessibility issue at all, it's simply expected behaviour. If people are used to being able to do that in their browser then it should not be forced or suppressed in any way. Keyboard only users is an interesting one... so if the person is a keyboard user out of choice (as in they prefer to use the keyboard for ease of use) they might well be using a setup where it's not possible to highlight the submit button to submit it. Someone who is using the keyboard only because they have difficulty with a mouse is unlikely to have that problem as they'd choose a setup which allows them to do that. As for putting line breaks in the field, as far as I know no browsers will submit a form when you press enter on a textarea, and as input type=field /'s are only one line, they surely wouldn't expect to be able to put a line break there anyway. I actually publish a blog post on a very similar topic (although not so focussed on the accessibility side of things) yesterday: http://www.norestfortheweekend.com/2009/10/20/on-forms-submit-buttons-and-browsers/ I hope you find it interesting! Mark On 21 Oct 2009, at 04:39, Chris Vickery wrote: Thanks Jason, In this case it’s for an input field, not a textarea, and enter will still not submit (unless you tab out) so in this case makes it contrary to ‘native browser behaviour’. Essentially our input fields would, (although they identify themselves as input fields) would behave like textareas, without line breaks. I’m not really familiar with using a text to speech reader, but that sounds messy to me. Interestingly the source itself looks pretty straight forward: div id=abc-form class=form form name=abcform id=abcform method=post action= input type=text name=abcform[email1] value= id=email1 class=text /input type=submit name=form[subscribebutton1] value=Subscribe id=subscribebutton1 / /form /div There must be something buried in the styling causing this behaviour. Chris *From:* li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.orgli...@webstandardsgroup.org ] *On Behalf Of *ja...@flexewebs.com *Sent:* Wednesday, 21 October 2009 11:03 AM *To:* wsg@webstandardsgroup.org *Subject:* Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED] Hi Chris, The submission by pressing enter is a native browser behaviour, hence is not an accessibility issue. You will only be able to submit via enter from an input field and not from a textarea, which you have to tab out of and then hit enter. So I doubt you will find any references to back-up your claim. If you do, send it through so we can debunk it. :-D Best, Jason Sent from my BlackBerry® wireless device -- *From: *Chris Vickery chris.vick...@privacy.gov.au *Date: *Wed, 21 Oct 2009 10:20:51 +1100 *To: *...@webstandardsgroup.orgwsg@webstandardsgroup.org *Subject: *[WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED] We’re accessibility testing at the moment. We’ve got some email forms (ie. Put in your email address to subscribe - submit) that do not currently submit if you press enter. Personally I feel this should be an accessibility issue, but I am finding it difficult to locate any solid documentation to back up my claim. I’ve had the argument put to me that a keyboard only user could still tab to the submit button, then press enter, but this seems very unintuitive to me to force users to do this. I’ve also had put to me that some users get confused if they want to put line breaks in a field and submit by accident... and so to be consistent pressing enter should never submit a form. (data entry people would love that one :P) Is submitting by pressing enter from
Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED]
2009/10/21 Chris Vickery chris.vick...@privacy.gov.au: In this case it’s for an input field, not a textarea, and enter will still not submit (unless you tab out) so in this case makes it contrary to ‘native browser behaviour’. This would potentially create annoyance to users of Safari on an iPhone or iPod Touch. When you have a text input focused (in contrast to a textarea) Mobile Safari displays a big blue [ Go ] button in the bottom right corner which one would expect will submit the form (equivalent to hitting Enter). If Enter does not submit the form it will be necessary for Mobile Safari users to leave the 'form mode' by clicking [Done] and then manually tap the submit button. I would consider this unexpected behaviour a usability issue at very least. Cheers Ollie -- @ollicle *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED]
Return Receipt Your Re: [WSG] Is pressing Enter to submit (or not) on forms an document: accessability issue? [SEC=UNCLASSIFIED] wasdlapcew...@fs.fed.us received by: at:10/21/2009 08:20:47 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] a table layout issue
On Thu, Sep 24, 2009 at 6:23 PM, tee weblis...@gmail.com wrote: ore conservative as it's not making sense to use it if I still have to insert div in the cell for IE6 (7 too?!) You can see the final result here by adding two products to cart (use Firefox as I have not checked in other browsers yet): http://submarine2.etrivo.com It's been almost a month that I am finally going to wrapping up this project and is starting to perform IE browsers check. The code is based on Kepler's http://www.coolphptools.com/tests/tr.html Alas, it doesn't work for IE. Turns out IE doesn't like border-spacing. I have not checked it on IE8 but don't think this will make a difference. http://submarine2.etrivo.com/border-spacing.png Going to try Alex's method now. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] a table layout issue
On Oct 21, 2009, at 3:27 PM, weblist99 wrote: Alas, it doesn't work for IE. Turns out IE doesn't like border- spacing. I have not checked it on IE8 but don't think this will make a difference. http://submarine2.etrivo.com/border-spacing.png Going to try Alex's method now. tee Oops, no need to try, just checked, same issue with border-spacing. http://submarine2.etrivo.com/border-spacing.png tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] a table layout issue
On Oct 21, 2009, at 3:32 PM, tee wrote: Oops, no need to try, just checked, same issue with border-spacing. http://submarine2.etrivo.com/border-spacing.png Sorry, wrong url. http://submarine2.etrivo.com/border-spacing-alex.png tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED]
Thanks everyone for the feedback. Lots to work with there. Good stuff. -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Oliver Boermans Sent: Wednesday, 21 October 2009 8:58 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Is pressing Enter to submit (or not) on forms an accessability issue? [SEC=UNCLASSIFIED] 2009/10/21 Chris Vickery chris.vick...@privacy.gov.au: In this case it's for an input field, not a textarea, and enter will still not submit (unless you tab out) so in this case makes it contrary to 'native browser behaviour'. This would potentially create annoyance to users of Safari on an iPhone or iPod Touch. When you have a text input focused (in contrast to a textarea) Mobile Safari displays a big blue [ Go ] button in the bottom right corner which one would expect will submit the form (equivalent to hitting Enter). If Enter does not submit the form it will be necessary for Mobile Safari users to leave the 'form mode' by clicking [Done] and then manually tap the submit button. I would consider this unexpected behaviour a usability issue at very least. Cheers Ollie -- @ollicle *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** WARNING: The information contained in this email may be confidential. If you are not the intended recipient, any use or copying of any part of this information is unauthorised. If you have received this email in error, we apologise for any inconvenience and request that you notify the sender immediately and delete all copies of this email, together with any attachments. *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
