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] div over flash
It is impossible to get a div sitting on top of flash in all browsers. Your best bet is to hide the flash while your overlay is showing and show it when it hides again. If the blank space where your flash was will be obvious you could set a background image similar-looking to the flash on it's container div. Mark 2008/10/23 kevin mcmonagle [EMAIL PROTECTED] hi, forgive me if this it ot, if so please reply off list. Whats the best cross-browser way to get a div on top of swf with css. If i use: param name=wmode value=opaque / with z-index will it be sufficent? -best kevin *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Incorporating Terms and Cons in signup page
Well we've been working on a global sign in and registration system for some time now and the conclusion we've come to with the T's C's is to not include it in the page by default - have a link to it and hope that when the user clicks back their user agent will repopulate the fields (as most seem to these days). For the javascript enabled we pull in the text via ajax and store it in a scrollable div so it doesn't take up too much screen real-estate. Hope that helps Mark On Tue, Sep 30, 2008 at 2:15 PM, John Unsworth [EMAIL PROTECTED]wrote: Hi WSG, I'm wondering about the best method to incorporate in a signup form a Terms and Conditions agreement, which being so long will be bought to the page externally. Or if it's thought best, maybe not! On a previous occasion I went forward using the object tag. The advantage to my mind is that, my document (that may change in future) is separate to the form and for those who don't have a browser capable of using the object tag, can see alternative text to link to the separately hosted TC page. But it's been put to me at work, there might be a way to house the document in a div, give the div a fixed size and make it scrollable. Alternatively I could use a textarea element, although I'm given to understand it would need to be outside the form so as not include it in the 'Signup' event when the submit button is clicked. However to satisfy the designer, who follows that the convention is that the form is visually seen before the last submit button, I'd use CSS to position it - but that doesn't sound very semantic to me? Putting it on another page, that you would link to, read, then return to the form to agree to has been rejected for the sanctity of the concept of a single page signup document. I hope I've been clear, and I guess I'm interested in anything similar to this in best practice, accessibility and standards. Cheers for just being there folks, John Unsworth *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Wrapping multiple paragraphs around an image
Good evening folks, Does anyone know a good method of wrapping the text of multiple paragraphs around a single (large) image? It's possible I'm having a brain malfunction but I can't think of a good way to do it. All I can come up with is: 1) Combine all paragraphs into one and separate with br /, then simply float the img / within the p. This is horribly un-semantic and won't be used - don't worry! 2) Float the images outside the ps and make do with wrapping on a per-paragraph basis. 2 is not ideal as I'd like the text to wrap around the image on the next line after the bottom of the image. Does anyone know how to achieve this while maintaining standards, accessibility, semantics etc,? Thanks! Mark *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Wrapping multiple paragraphs around an image
...rather embarrassingly option 2 seems to work as I'd hoped it would and not as I expected it to. So I suppose that raises the question: What's the best way to NOT wrap text around an image but maintaining a fluid layout (so you can't fix the width of the ps)? I guess you could put all the text into a div but surely there's a better way without the extra markup... Mark On 14 Aug 2008, at 18:36, Mark Stickley wrote: Good evening folks, Does anyone know a good method of wrapping the text of multiple paragraphs around a single (large) image? It's possible I'm having a brain malfunction but I can't think of a good way to do it. All I can come up with is: 1) Combine all paragraphs into one and separate with br /, then simply float the img / within the p. This is horribly un- semantic and won't be used - don't worry! 2) Float the images outside the ps and make do with wrapping on a per-paragraph basis. 2 is not ideal as I'd like the text to wrap around the image on the next line after the bottom of the image. Does anyone know how to achieve this while maintaining standards, accessibility, semantics etc,? Thanks! Mark *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Browsers and Zooming
I wonder what a partially sighted user would thing of these 'improvements'. Would they be glad that now they can see images a little easier and the layout seems to break less or would they be annoyed at the sudden appearance of a horizontal scrollbar? On Thu, Jul 3, 2008 at 2:14 PM, James Leslie [EMAIL PROTECTED] wrote: The latest versions of the 4 major browsers (IE, Opera, Safari and Firefox) all do zooming. It is *relatively* safe to assume that Firefox, Safari and Opera users will update their browsers on a regular basis as these browsers all have to be sought out and downloaded initially. However IE6 still hangs around and doesn't support page zooming, so I believe that you still have to check font resizing on layouts rather than assuming that all users can zoom. Font resizing is also available on all browsers so should be tested for anyway. That's my thought anyway. -- Are all browsers now using zooming to resize pages? I noticed FF2 wasn't using zooming but FF3 is and I know IE and Safari already do it. Any background information in this? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Browsers and Zooming
That's such a good point - that's been available since Windows 95 - possibly before. Surely if that's the behaviour they were after they would just use the functions built in to the operating system. Mark On Thu, Jul 3, 2008 at 3:21 PM, Patrick Lauke [EMAIL PROTECTED] wrote: -- *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Mark Stickley *Sent:* 03 July 2008 14:56 *To:* wsg@webstandardsgroup.org *Subject:* Re: [WSG] Browsers and Zooming I wonder what a partially sighted user would thing of these 'improvements'. Would they be glad that now they can see images a little easier and the layout seems to break less or would they be annoyed at the sudden appearance of a horizontal scrollbar? Or would they be using screen magnification software anyway, and it wouldn't make a difference to them? P Patrick H. Lauke Web Editor Enterprise Development University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 [EMAIL PROTECTED] www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
