RE: [WSG] Visited links
Have you checked that you have the pseudo classes in the right order in the CSS? See http://www.w3schools.com/css/css_pseudo_classes.asp Grant On Fri, 11 Nov 2005 19:18:18 +1030, Tim Burgan wrote: Do you have any suggestions as to how to overcome this? ** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Video of Screen Reader Use?
Does anybody have, or know of any video of users on the Internet with a screen reader? While managers listen to the arguments about accessibility, I would like to appeal to their emotions as well. It is much easier to empathise with a person, than facts and figures. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Video of Screen Reader Use?
I managed to convince mine by suggesting our organsiation's website as an example site during the screen reading element of an accessibility conference. She was present...and far less amused than I. ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Lindsay Sent: Monday, 14 November 2005 9:05 AM To: wsg@webstandardsgroup.org Subject: [WSG] Video of Screen Reader Use? Does anybody have, or know of any video of users on the Internet with a screen reader? While managers listen to the arguments about accessibility, I would like to appeal to their emotions as well. It is much easier to empathise with a person, than facts and figures. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Video of Screen Reader Use?
Hi Joseph,These are really great videos from the University of Wisconsin.http://www.doit.wisc.edu/accessibility/video/I have shown these in a lot of classes and presentations.Sincerely,Justin ThorpOn Nov 13, 2005, at 5:04 PM, Joseph Lindsay wrote:Does anybody have, or know of any video of users on the Internet witha screen reader?While managers listen to the arguments about accessibility, I wouldlike to appeal to their emotions as well. It is much easier toempathise with a person, than facts and figures.**The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help** *** Justin Thorp Technical Assistant Michigan State University Academic Computing Network Services - Applications Programming http://approg.msu.edu/ Principal; Web Developer Accessibility Specialist MyCapitalWeb.com LLC 3016 S. Deerfield Lansing, MI 48911 [EMAIL PROTECTED] my NEW personal blog - http://www.justinthorp.com my web development blog - http://thinkthentype.blogspot.com
Re: [WSG] Video of Screen Reader Use?
If you want to appeal to their emotions you may want to have them try this demo site http://www.drc-gb.org/newsroom/website1.asp Its no video but gives them a damn good idea of what its like. At the left are the online demos and at the bottom left is a SR demo. Joseph Lindsay wrote: Does anybody have, or know of any video of users on the Internet with a screen reader? While managers listen to the arguments about accessibility, I would like to appeal to their emotions as well. It is much easier to empathise with a person, than facts and figures. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Accessibility: Default placeholders
Is it really necessary for accessibility to include default place-holding characters in edit boxes and text areas per WCAG 1.0 Checkpoint 10.4? Is that an obsolete guideline? 10.4 *Until user agents* handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] For example, in HTML, do this for TEXTAREA and INPUT. http://www.w3.org/TR/WCAG10-TECHS/#tech-place-holders Have we reached (or largely reached) the until user agents stage yet? What implications is ignoring this guideline likely to have (other than not getting tick marks from various automated tools), given I use properly coded labels and (where needed) fieldsets for the inputs? It seems crazy to repeat the label text (or slightly amended info) in the input for people to overwrite (and some will perhaps leave it in there!) Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On Mon, 14 Nov 2005 08:31:21 +0800, Bert Doorn wrote: Have we reached (or largely reached) the until user agents stage yet? What implications is ignoring this guideline likely to have (other than not getting tick marks from various automated tools), given I use properly coded labels and (where needed) fieldsets for the inputs? I am reliably informed we have reached that point and that including default text now causes more problems than it solves. However I do not have many references to back this up - http://www.accessifyforum.com/viewtopic.php?t=3346 is one public discussion. Note that it doesn't appear in WCAG 2.0 Other non-public discussions that I have archived suggest that it should always be scripted away, and not shown if javascript is disabled, and that a space is a good value if you really want to do it. HIH! Lea -- Lea de Groot Elysian Systems - http://elysiansystems.com/ Brisbane, Australia ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Bert Doorn wrote: Is it really necessary for accessibility to include default place-holding characters in edit boxes and text areas per WCAG 1.0 Checkpoint 10.4? Is that an obsolete guideline? Personally, I'd say it is an obsolete guideline indeed. However, I recently heard on the WAI IG list that some braille software requires at least a space as a placeholder, otherwise it just does not expose inputs to the user. I'd argue that this is a fault of the software...but it's something that might have to be taken into consideration. http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/0034.html -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 14/11/2005, at 11:31 AM, Bert Doorn wrote: Is it really necessary for accessibility to include default place-holding characters in edit boxes and text areas per WCAG 1.0 Checkpoint 10.4? Is that an obsolete guideline? ... Have we reached (or largely reached) the until user agents stage yet? What implications is ignoring this guideline likely to have (other than not getting tick marks from various automated tools), given I use properly coded labels and (where needed) fieldsets for the inputs? It seems crazy to repeat the label text (or slightly amended info) in the input for people to overwrite (and some will perhaps leave it in there!) Leaving it there can be a problem. I have seen a demonstration (at a Melbourne WSG meeting, no less) where the agent placed the cursor at the end of the place-holding text without reading it. There is a real danger that the user will enter text without knowing that the place-holding text is there. 10.4 has been deprecated in the WCAG 2.0 Working Draft, if that helps any. http://www.w3.org/WAI/GL/2005/06/30-mapping.html But it's only draft, remember. -- Jonathan O'Donnell mailto:[EMAIL PROTECTED] http://purl.nla.gov.au/net/jod +61 4 2575 5829 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Accessibility: Default placeholders
I ran a usability evaluation last week where some (few) of the form elements had place-holding text and others didn't. This caused problems as you might expect as users scanned over those fields thinking that as they were already populated, they were therefore optional. Of course they were mandatory and caused validation errors. This was more an issue of inconsistent design, though it does illustrate possible usability/accessibility issues. Lisa -Original Message- From: Jonathan O'Donnell [mailto:[EMAIL PROTECTED] Sent: Monday, 14 November 2005 11:55 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility: Default placeholders Leaving it there can be a problem. I have seen a demonstration (at a Melbourne WSG meeting, no less) where the agent placed the cursor at the end of the place-holding text without reading it. There is a real danger that the user will enter text without knowing that the place-holding text is there. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Lea de Groot wrote: I am reliably informed we have reached that point and that including default text now causes more problems than it solves. However I do not have many references to back this up - Possibly worth adding to this empirical evidence: I spoke to Shawn Lawton Henry of the W3C's WAI EOWG about 1 1/2 years ago at a workshop in Madrid, and she confirmed that, in her interpretation, it's pretty much an obsolete guideline. -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Patrick H. Lauke wrote: Bert Doorn wrote: Is it really necessary for accessibility to include default place-holding characters in edit boxes and text areas per WCAG 1.0 Checkpoint 10.4? Is that an obsolete guideline? Personally, I'd say it is an obsolete guideline indeed. However, I recently heard on the WAI IG list that some braille software requires at least a space as a placeholder, otherwise it just does not expose inputs to the user. I'd argue that this is a fault of the software...but it's something that might have to be taken into consideration. http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/0034.html Why can't the braille software detect an empty form element and inform the user it requires data? Is this an authoring tool problem or a problem with the way standards are prescribed? I agree with this from two perspectives 1) that to address this to the nth degree, where it is actually a problem with either the way the software functions or is a bug. How much of our time do we spend addressing bugs in user agents? Isn't so much of the information on lists like this sharing insights into how to address bugs in user agents. I think this is what turns non standards developers off standards development. Admittedly tag soup has it's own set of bugs, but being a standards developer means, to me, you have to be prepared to work with lots of buggy software, far more than should reasonable be expected. 2) often I feel place holders are not good usability, because the forms themselves should be designed well enough to represent the data sets required. I think it can add to all sorts of cognitive problems in complex screens. Regards Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Jonathan O'Donnell wrote: Leaving it there can be a problem. I have seen a demonstration (at a Melbourne WSG meeting, no less) where the agent placed the cursor at the end of the place-holding text without reading it. There is a real danger that the user will enter text without knowing that the place-holding text is there. Yes, I'm not surprised at this observation at all. --- Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Herrod, Lisa wrote: I ran a usability evaluation last week where some (few) of the form elements had place-holding text and others didn't. This caused problems as you might expect as users scanned over those fields thinking that as they were already populated, they were therefore optional. Of course they were mandatory and caused validation errors. This was more an issue of inconsistent design, though it does illustrate possible usability/accessibility issues. Lisa Exactly, and how many users make the same mistake on complex pages where the form fields are pre populated, thinking that the system has added the appropriate data or is not inviting the user to add data. *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. If users are used to working on complex data retrieval systems, where there is a lot of read only data, then they will be confused by this because this type of design breaks the standard by which GUI's function. If this type of design continues, it will only confuse users more. -- Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Accessibility: Default placeholders
Yes this is an interesting point. And it differs from visually highlighting a field once the user has encountered a form validation error. For example, a user misses or incorrectly fills out a mandatory field and when the form is re-presented, those fields are visually highlighted with a background colour. In this example, I find users actually like this method and find it useful/helpful. -Original Message- From: Geoff Deering [mailto:[EMAIL PROTECTED] *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. If users are used to working on complex data retrieval systems, where there is a lot of read only data, then they will be confused by this because this type of design breaks the standard by which GUI's function. If this type of design continues, it will only confuse users more. -- Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 11/14/05, Geoff Deering wrote: Why can't the braille software detect an empty form element and inform the user it requires data? Is this an authoring tool problem or a problem with the way standards are prescribed? Agreed, Geoff. We really do need to know more. We'll need to add this to the hitlist for the WaSP Accessibility Task Force. It is something that is of concern to all - I'll see about running some tests with a local braille display user and see what I can determine from his tests... Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
G'day Thanks for all the replies, you've confirmed my suspicions. It's unfortunate that online accessibility/quality checking tools still insist on this (especially when you have a client who likes to see a mass of ticks with every tool you throw at his site). I have the same concerns others voiced about there already being data in the field - it's confusing and may cause more problem than it fixes. I hate having to manually select text already in an input, to overwrite it. Yes, that can be overcome with javascript, but I'd rather not fix a problem by introducing another potential problem. I might settle on adding value= (space) - shouldn't be hard to change my scripts to strip leading spaces when checking if a field has been completed. Geoff, I know exactly what you mean with the greyed out fields. Came across it myself only yesterday - a form where all inputs had a grey background. It wasn't until I clicked in one of them that I realised the field was not disabled. Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Herrod, Lisa wrote: Yes this is an interesting point. And it differs from visually highlighting a field once the user has encountered a form validation error. For example, a user misses or incorrectly fills out a mandatory field and when the form is re-presented, those fields are visually highlighted with a background colour. In this example, I find users actually like this method and find it useful/helpful. This may work okay for visual users, but it has no means of communicating with those who cannot rely on visual indicators. This leads to something that has not enough attention has been drawn to; Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Leave fields that do not meet this criteria outside this group, either in a separate group or ungrouped. This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. It is a much better practice to group all these fields together. Not only is it better accessibility practice, I feel it offers better usability by design. -- Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 14/11/2005, at 1:02 PM, Bert Doorn wrote: ... I might settle on adding value= (space) - shouldn't be hard to change my scripts to strip leading spaces when checking if a field has been completed. ... Hi Bert I would have thought that you would want to make your scripts check for leading _and trailing_ spaces. Mouse users will often click into the start of a field. When they enter text, they will end up with a trailing space. Jonathan -- Jonathan O'Donnell mailto:[EMAIL PROTECTED] http://purl.nla.gov.au/net/jod +61 4 2575 5829 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Derek Featherstone wrote: On 11/14/05, Geoff Deering wrote: Why can't the braille software detect an empty form element and inform the user it requires data? Is this an authoring tool problem or a problem with the way standards are prescribed? Agreed, Geoff. We really do need to know more. We'll need to add this to the hitlist for the WaSP Accessibility Task Force. It is something that is of concern to all - I'll see about running some tests with a local braille display user and see what I can determine from his tests... See my previous post to Lisa. I think this actually needs a major article on ALA or somewhere where it gets a lot of exposure. Your blog would be okay too. I encourage you or Patrick to write something addressing this. Also need to address this issue of greying input fields (which indicates read only status). --- Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Bert Doorn wrote: Geoff, I know exactly what you mean with the greyed out fields. Came across it myself only yesterday - a form where all inputs had a grey background. It wasn't until I clicked in one of them that I realised the field was not disabled. Yes, someone please, who writes for some of the major design magazines or ezines, please address this before it gets too out of hand because I feel a lot of people are implementing this, not realising that it does have a standards based meaning as an interface design attribute. Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
G'day I would have thought that you would want to make your scripts check for leading _and trailing_ spaces. Mouse users will often click into the start of a field. When they enter text, they will end up with a trailing space. Although I tend to click somewhere in the middle (rather than do gymnastics to move my mouse to the beginning of the box), it's a good point. Not everybody is like me (which is just as well :-) Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] PNG Question
Greetings all, I wanted to see what people's comments were as to using .png's vs. .gifs these days. I have a design that will require those nice transparency effects only a .png can provide if I want it to be just like the mockup. Do most browsers support that yet, or do I have to go with the gif that has been carefully shaved? If you care, the mockup is http://sausalito.sitesbyjoe.com/ and the shadow in question is on the logo - the problem is created by the pattern in the background behind it - blah blah blah. Thanks, Joe Taylor http://sitesbyjoe.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Geoff Deering wrote: *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. The problem with this is obviously that it's difficult to say *how* grey an input has to appear before a user thinks it's read only. Do we sit down and define a required luminescence/contrast to the background? In my mind, hard to quantify other than to say: be careful, don't make it too dark/grey, otherwise some users may think they can't use them. -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] PNG Question
Only supported in IE 6 with a hack, kind of an ugly one too as it renders the PNG's transparent area with a mid gray until it has finished loading, I guess if it's on a small image it's ok. Joseph R. B. Taylor wrote: Greetings all, I wanted to see what people's comments were as to using .png's vs. .gifs these days. I have a design that will require those nice transparency effects only a .png can provide if I want it to be just like the mockup. Do most browsers support that yet, or do I have to go with the gif that has been carefully shaved? If you care, the mockup is http://sausalito.sitesbyjoe.com/ and the shadow in question is on the logo - the problem is created by the pattern in the background behind it - blah blah blah. Thanks, Joe Taylor http://sitesbyjoe.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] PNG Question
Joseph R. B. Taylor wrote: I have a design that will require those nice transparency effects only a .png can provide if I want it to be just like the mockup. Do most browsers support that yet, or do I have to go with the gif that has been carefully shaved? IE does not natively support 24 bit alpha transparency on PNGs without some seriously hacky workarounds. http://www.alistapart.com/stories/pngopacity/ Also, if you're still getting visits from users of older browsers such as Netscape 4.x (yes, I know, less and less of a consideration, but worth mentioning nonetheless) GIF is the safest choice (as they don't even understand 8 bit PNGs). P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. The problem with this is obviously that it's difficult to say *how* grey an input has to appear before a user thinks it's read only. Do we sit down and define a required luminescence/contrast to the background? In my mind, hard to quantify other than to say: be careful, don't make it too dark/grey, otherwise some users may think they can't use them. I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 11/14/05, Geoff Deering wrote: Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Indeed - one of my favourite techniques: http://simplyaccessible.org/examples/required-form-fields This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. Agreed. Putting them after *visually* and leaving them before in source order, and as part of the label can be really useful - its semantically meaningful, can be emphasized (using label em /em/label) as shown in the second example on that page is useful. You could easily use the same technique to emphasize the text required instead of an asterisk. Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] PNG Question
Additionally: you may be best off using a fallback mechanism, so that browsers which are not capable of displaying 24 bit PNGs can still get *something*. An idea (by no means the best around) is my little experiment in PNG image replacement http://www.splintered.co.uk/experiments/19/ -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Geoff Deering wrote: I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. With all due respect, that sounds a tad too draconian for my tastes...and it's exactly the kind of talk that will make web *designers* simply stop listening to anything we say about standards and accessibility. It's a design and usability issue (with obvious accessibility implications stemming from it) that cannot be boiled down to a simple, one size fits all rule. It needs to be evaluated on a case by case basis. -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] PNG Question
Hi I've had fairly good results using PNGs, however IE on Windows does not support transparency in PNGs and usually replaces it with a grey filler colour. A situation at work meant I simply had to use some PNGs with transparency, and make them work in IE, which lead me to PieNG (http://www.bazon.net/mishoo/articles.epl?art_id=430) The script gets around the problem with some IE filters and a transparent gif. It wasn't quite over though, I can't remember why now, but this script does not work on images which are not visible when the page loads e.g. those used for mouse over effects. I re-wrote some of it to remove that limitation and can dig it out if you like. One last issue I had with PNGs was trying to match them to background colours specified in CSS which proved to be seriously hit and miss but if you play with the settings enough it can be done. The difference was only slight but enough to upset a few people. Adam H p.s. my first post on here... Greetings all, I wanted to see what people's comments were as to using .png's vs. .gifs these days. I have a design that will require those nice transparency effects only a .png can provide if I want it to be just like the mockup. Do most browsers support that yet, or do I have to go with the gif that has been carefully shaved? If you care, the mockup is http://sausalito.sitesbyjoe.com/ and the shadow in question is on the logo - the problem is created by the pattern in the background behind it - blah blah blah. Thanks, Joe Taylor http://sitesbyjoe.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] PNG Question
Patrick H. Lauke said: IE does not natively support 24 bit alpha transparency on PNGs without some seriously hacky workarounds. ...which is to say that IE *does* support 8-bit transparency (i.e. same as gif). The other gotcha you need to watch out for is the gamma correction applied by different browsers which can cause problems with color matching. Futher discussion and comparision table at: http://hsivonen.iki.fi/png-gamma/ kind regards Terrence Wood. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 14 Nov 2005, at 12:22 pm, Geoff Deering wrote: *Another* thing I see that is happening in design a lot lately is that input fields are in greyed background by design, not function. What this is telling the user is that that field is *read only*. That is the standard way operating systems manage read only data, and the same way it is done on web based systems. It's absolutely sending the wrong message to users, when the input field is open to accept data input. The problem with this is obviously that it's difficult to say *how* grey an input has to appear before a user thinks it's read only. Do we sit down and define a required luminescence/contrast to the background? In my mind, hard to quantify other than to say: be careful, don't make it too dark/grey, otherwise some users may think they can't use them. I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. Philippe --- Philippe Wittenbergh http://emps.l-c-n.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Patrick H. Lauke said: I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. With all due respect, that sounds a tad too draconian for my tastes...It needs to be evaluated on a case by case basis. Ah, well, if you (royal you) really *must* use grey (out of the the 65 million that are usually available), at least do some user testing to see if users thinks the field is disabled or not. Sounds like a job for cognitive walkthrough: http://www.pages.drexel.edu/~zwz22/CognWalk.htm kind regards Terrence Wood. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Derek Featherstone wrote: Agreed. Putting them after *visually* and leaving them before in source order, and as part of the label can be really useful - its semantically meaningful, can be emphasized (using label em /em/label) as shown in the second example on that page is useful. You could easily use the same technique to emphasize the text required instead of an asterisk. Yes, I agree, doing both is probably a better option as the asterisks has become a standard flag for marking required fields visually. It's too hard to go back now. I'm a minimalist, so I'd just use the fieldset, but I think your solution offers better overall usability (and accessibility). - Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Philippe Wittenbergh said: This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. A quick test of unstyled input type=text on winXP and IE6 reveals there is *no indication at all* that a field is disabled. Nice one IE6. Oh, I lie or I'm tired, the outline may have an indiscernable gaussian blur into the field. FF is grey, as is Opera. kind regards Terrence Wood ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Accessibility: Default placeholders
Geoff Deering wrote: Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Leave fields that do not meet this criteria outside this group, either in a separate group or ungrouped. I can't agree with this Geoff. There are many examples where some fields are mandatory and others optional but need to be in one fieldset group. Some examples include; first and surname mandatory, middle name optional, home phone mandatory, fax or mobile optional, addresses where extra optional fields are added for long or complex addresses. This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. The standard that I had used for the past several years was to place a statement at the start of the form explaining the significance of the asterisk. These are then included within the field labels and are read by screen readers (use text asterisk not an image). Any errors identified upon validation are listed at the top of the form (after the asterisk description) and preferably include a link to go to the offending field(s). The fields in error should also be identified both visually and textually (ref http://telstra.com.au/standards/docs/accb_03001.doc page 27). Regards Graham Cook www.uaoz.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Perth Meetups
Hi Guys, I only recently joined this list. According to the web site there are quite a few people based in Perth so I was interested to hear if there are any plans for meetups in the future? Lloyd ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Patrick H. Lauke wrote: Geoff Deering wrote: I think it is quite simple, don't use any scale of grey at all. Grey is reserved for meaning *read only*. With all due respect, that sounds a tad too draconian for my tastes...and it's exactly the kind of talk that will make web *designers* simply stop listening to anything we say about standards and accessibility. It's a design and usability issue (with obvious accessibility implications stemming from it) that cannot be boiled down to a simple, one size fits all rule. It needs to be evaluated on a case by case basis. With all due respects this is the way default graphical user interface on operating systems are designed to function. This is what the user agent should adhere too, the basic principles that form GUI standard software design, and it is something that designers should understand when implementing their design, because if they fail to do so, it most likely will cause both usability and accessibility issues. If you set any input control to read-only this is how it will behave, this is how it communicates to the user; This field is read only. That is what it means visually, it is greyed by default. From page 158 of The Windows Interface Guidelines for Software Design; You can also use text boxes to display read-only text that is not editable, but still selectable. When setting this option with the standard control, the system automatically changes the background color of the field to indicate to the user the difference in behaviour. Notice it doesn't say greyed, it just says it changes the background color, because this is under the control of the custom settings of the users desktop. This also leads to another problem, in that if users configure their operating system to a custom scheme, unwittingly the web designer may be indicating to the user that a field may be read only even if it is not grey. How does the designer know whether to use grey or not? They don't. All they know is the majority of users probably do not customise this setting. This is why I believe that it is best to not style form controls (or at least minimally), they can differ dramatically, not only over various operating systems, but over various versions and implementations of those operating systems, and the various custom desktop that the designer has no idea is being superimposed over their design, or visa versa. If you don't style form control I think it is less taxing cognitively. I used to style them, but I have abandoned that long ago because I think users become so used to seeing the standard controls of their operating system, that on complex pages, it begins to become too difficult to easily recognise them, IMHO. -- Geoff Deering I think Bert D ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Philippe Wittenbergh wrote: This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. Philippe --- I agree with this observation exactly Philippe. I addressed this somewhat in my post to Patrick. - Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Perth Meetups
Lloyd wrote: I only recently joined this list. According to the web site there are quite a few people based in Perth so I was interested to hear if there are any plans for meetups in the future? Hi Lloyd, Welcome to the list. :-) There is a Perth WSG but it will probably be in the New Year when we meet again. When we have the next date, it will be announced on the WSG Announce list (to which you are subscribed by default when you join the WSG). Feel free to email Kay Smoljak (the other Perth organiser) and myself directly (using perth at webstandardsgroup dot org will reach us both) if you want further information. (That way we can keep such discussions off the list so that the 2000 subscribers who are not in Perth aren't unnecessarily annoyed.) It will be nice to meet you there. Vicki. :-) -- Vicki Berry DistinctiveWeb Web: http://www.distinctiveweb.com.au Blog: http://www.unheardword.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Terrence Wood wrote: Philippe Wittenbergh said: This makes kind of good argument for *not* styling form inputs at all, and leave it to the OS. On most of my OS X browsers, disabled form fields are not really greyed out, but rather use opacity reduction to indicate read-only. A quick test of unstyled input type=text on winXP and IE6 reveals there is *no indication at all* that a field is disabled. Nice one IE6. Oh, I lie or I'm tired, the outline may have an indiscernable gaussian blur into the field. FF is grey, as is Opera. kind regards Terrence Wood Yes, I'd really like to know the usability studies that changed the design of form controls so dramatically when MS designed XP. The buttons I think are fine, but the form fields... I'd just like to know how they were scene as an improvement? There are both *readonly* and *disabled* attributes in input elements. My main exposure to this was an Intranet application I was working on in 2000, aimed at IE5. Like many things that aren't major issues, I don't think it is well supported. I haven't done a general check on this for ages, to see how well it is supported these days. -- Geoff ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
Graham Cook wrote: Geoff Deering wrote: Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Leave fields that do not meet this criteria outside this group, either in a separate group or ungrouped. I can't agree with this Geoff. There are many examples where some fields are mandatory and others optional but need to be in one fieldset group. Some examples include; first and surname mandatory, middle name optional, home phone mandatory, fax or mobile optional, addresses where extra optional fields are added for long or complex addresses. Yes, I agree with you on that. Maybe there is a better way to approach those problems. Don't have an answer to it. In general though, I'd try and stick with what I have said before, but as you have pointed out here, there are obvious cases that don't easily fit to be able to present a logical flow of information. This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. The standard that I had used for the past several years was to place a statement at the start of the form explaining the significance of the asterisk. These are then included within the field labels and are read by screen readers (use text asterisk not an image). Any errors identified upon validation are listed at the top of the form (after the asterisk description) and preferably include a link to go to the offending field(s). The fields in error should also be identified both visually and textually (ref http://telstra.com.au/standards/docs/accb_03001.doc page 27). I think this is good implementation, but I think it makes it much less taxing on non visual users if such form fields can be clearly grouped together, but when this can't be done, it's fine. This also helps visual users. At lot of work went into the Telstra standards, it's a shame they never utilised the knowledge within Rob Pedlow's Research team, because those set of standards, that have been in use for almost half a decade, are full of holes and misunderstandings. -- Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Accessibility: Default placeholders
At lot of work went into the Telstra standards, it's a shame they never utilised the knowledge within Rob Pedlow's Research team, because those set of standards, that have been in use for almost half a decade, are full of holes and misunderstandings. The latest standards were published in March this year after extensive dialogue and input from Rob's team. The standards were to raise Telstra's conformance from priority level 1 to priority level 2. Unfortunately just after they were published Rob went overseas and Telstra closed down the standards department (I was the standards manager) leaving the business units to fend for themselves and effectively removing the link to Robs team. Graham Cook www.uaoz.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
