Re: [WSG] Accessibility of forms, do you always need a label with drop downs?
on 23/11/2006 12:48 Barney Carroll said the following: snip That's a great set of results - but I still wonder about things I'd consider far more obvious than the second half of methods, like visibility:hidden; and font-size:0;... There's an earlier survey from 2003 that covers visibility:hidden etc. http://css-discuss.incutio.com/?page=ScreenreaderVisibility Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] linked images in form labels
on 23/11/2006 15:40 Alexander J Jerabek said the following: Although this is valid (see snippet below), and there are alt and title tags for the image, does the following make sense from an accessibility or usability point of view? Are there any problems with this sort of markup? --snippet- label for=google a href=http://www.google.com/; img src=http://www.google.com/logos/Logo_40wht.gif; width=128 height=53 alt=Search Google title=Search the Internet using Google / /a /label input type=text name=q id=google value= / Well, those with poor vision won't be able to resize the label 'text' since you're using an image. In the meantime, I'd drop the title attibute, if I was you. It's just replicating the alt text (which could so with amending to just 'Search' or whatever the image actually says). Many screen reader users won't hear the title attribute at all but, if they do, all it will contribute is unnecessary noise. HTH Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] xhtml strict break tag bug?
on 17/11/2006 14:36 [EMAIL PROTECTED] said the following: Maybe should mention that these are menu links If this is a menu, she should be using a list - not line breaks - for a whole host of reasons. Styling the padding/margins on the list elements then becomes a lot easier. I'm not convinced that br / *should* be stylable in the way she sems to want. It's not a page element as such, merely a signal to perform a carriage return and line feed when redenring. As such the line height should be the same as that set for the rest of the paragraph. This does not happen in her xhtml transitional version. It could be that FF and Moz are being thrown into 'almost standards' mode: http://developer.mozilla.org/en/docs/Gecko%27s_Almost_Standards_Mode Side note: I've noticed in her html she is using tabindex, is that standard? Yes - it's compliant and valid markup but unless there are *really* good reasons for specifying tab indexes, I suggest she removes them and checks that the natural, unindexed, tab order is intuitive (ie top-to-bottom, left-to-right for a Western page). If the page has been manually checked for keyboard navigation accessibility, any warnings from accessibility parsers can be safely ignored. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] xhtml strict break tag bug?
on 17/11/2006 16:46 Thierry Koblentz said the following: snip On the other hand, I have a question regarding accessibility: is a BR element as good as a printable character when it comes to separate these links? No. As far as I am aware, it's equivalent to use whitespace to separate links - which means that it could create probems for some users. I'm not sure if JAWS 7 can audibly separate the links itself. Certainly, older screen readers will have problems and, probably, anyone using a braille display. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
on 10/11/2006 05:03 [EMAIL PROTECTED] said the following: Please could someone tell me what I'm obviously missing? snip Your text for each input isn't enclosed by the label element so the explicit association is being lost. Instead of: label for=ainput type=radio value=0 name=answer alt=make your mark id=a accesskey=l tabindex=2 //labelTextbr / It should be label for=ainput type=radio value=0 name=answer alt=make your mark id=a accesskey=l tabindex=2 /Text/labelbr / Personally I'd also: 1. Scrap the accesskeys. All of the keys you're using conflict with keystrokes reserved for JAWS, Home Page Reader, Firefox/Mozilla and Opera 7: http://www.wats.ca/show.php?contentid=43 2. Get rid of the tabindexing. If your natural tab order is intuitive, you don't need it. The last thing you should do is interfere with the intuitive tab ordering on a page. It can drive keyboard navigators up the wall. 3. Get rid of the tabled layout. What you posted is simple enough to achieve without tabling. 4. Change the title attribute on your link from Off Site Link to Opens in new window. In fact, consider either not spawning a new window or placing the warning in clear text and, if necessary, using css to position it offscreen. A significant number of screen reader users configure their software to ignore the title attribute (because it's so over-used) so will not be pre-warned about the new window. Automated accessibility parser warnings about tab indexes and access keys can be safely ignored provided you've actually tested the keybaord navigation of the page yourself and you're happy that it behaves logically. Hope that helps Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
on 03/11/2006 00:59 Matthew Hodgson said the following: snip In the end, we learned the following lessons about vision impaired users and screen readers: a) Only a completely blind person used the screen reader. snip Although you were talking about visually-impaired users and screen readers, I just thought it was worth pointing out that those suffering from severe dyslexia often use screen readers for support. So it maybe unwise to assume that a screen reader user can't see. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
on 03/11/2006 07:50 kate said the following: What about users with cognitive disibilities? Its a very wide catagorie which includes, simple dyslexia to extreme mental retardation. Apparently these people regularly use the web as a primary imformation source so must be considered. Would they understand the wording 'Go to Menu' etc? Never having the need to use a screen reader its a question I wanted to ask. A dyslexic using a sreenreader for support almost certainly won't have a problem with the wording once they hear it. At the more extreme end of the cognitive issues group, it's highly likely that very basic concepts such as using links will escape them and they may have difficulty with all but the simplest of language. In these situations, users often need 'hand over hand' support (ie someone sitting with them - explaining and guiding them). Using conceptual icons can help both groups to some extent but there does come a a point when there is very little a designer can do to alleviate the problems and it's really down to training, support and experience at the user's end. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
on 03/11/2006 10:50 Rahul Gonsalves said the following: snip http://www.usability.com.au/resources/ozewai2005/ I wonder whether any of the conclusions that were drawn in the study, are still valid, or whether there has been further research to either supplement or contradict it? Specifically, one observation, The majority of screen reader users EXPECT navigation to be presented before the content. [1], and the subsequent statement Our research showed no clear overall PREFERENCE of source order [2], seem to lead me to believe that there is no real reason to attempt to have layouts with the source order first. snip I'd be interested to hearing from people with actual experience, and or research, since all my conclusions are arrived at second-hand. I also did a very small study on page order with some experienced pan-disability users/testers from the Shaw Trust (www..shaw-trust.org.uk) about a year ago. The feedback that I received confirmed the findings above. Users expected site navigation to be presented before content. Overall, the testers felt that placing content before navigation didn't offer any real benefits - especially as it was contrary to their expectations and previous experience. So it would seem that, once a 'trend' is well established, going against it (even for the best of reasons) can create its own issues. Users, generally, don't like being suprised or being made to think as they try to move around a site or page. In a separate, earlier, piece of research, I came across screen reader users who preferred to access content before navigation and achieved this by simply jumping to the bottom of the page and working upwards as standard. So it would seem that screen reader users are perfectly capable of developing their own individual strategies to maximise the chances of page content being rendered in the order that they prefer. But, again, this kind of strategy is based upon the expectation that content will be placed after navigation. If you design contrary to that expectation, the end result may be disorientations and/or frustration for this sub-group. In the past 12 months, I've not come across any newer studies that would suggest anything has changed. Hope that helps. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Articles/reasearch/experience of screen readers
on 03/11/2006 11:18 Barney Carroll said the following: snip By the way, could anyone elaborate on what tab-indexing is? And how does the Alt+# system work? These seem to be crucial elements of screen reader browsing but I have a very limited grasp of their convention and application. Tabindexing allow a designer to specify the order in which links or controls receive focus on a page when using the TAB key to move around. Elements on a page that do not have an associated tabindex will have a 'natural' ordering (ie follwong the order they appear in the markup). If you mix the two, the elements with a specified tabindex will come first followed by unindexed elements. Speaking as an intermittent keyboard navigator/VR user, I consider tabindexing to be the spawn of satan - especially when it runs contrary to the 'natural' or expected tab order on a page. For example, if I land on a page which renders some content containing a few links followed by a form, I expect to be able to tab to the links first followed by the forum controls. One common use of tabindexing that I come across in this situation gives preference to the form controls and leaves the links unindexed. So, when I hit the TAB key expecting to jump to the first link, I actually end up on the form and often have to tab through the whole thing to get back to the links which, visually, are actually higher up the page. The end result (especially if there is a lack of visual highlighting on focus) is often complete disorientations and exasperation. On really bad pages, I sometimes have to rely on reading the browser status bar just to try and figure out where I'm tabbing to! If I had one thing (OK- one thing amongst many) to ask of other designers it would be Please don't create tab orders that are unintuitive!. Users (in the West, anyway) expect tab ordering to follow a left-to-right top-to-bottom rule and, as soon as you mess with that, you create confusion. By the 'Alt+# system', I assume you mean accesskeys. It's a way of defining keyboard shortcuts which, in theory, allow users to jump to, for example, the Search item on the menu by selecting ALT+s. Depending on the browser being used, the user may then have to press ENTER to activate the link. The designer can define which keys, in conjunction with ALT (or CTRL on a Mac) relate to which links by means of the accesskey attribute. However, there are problems associated with defining accesskeys on a site as they can over-ride pre-existing keyboard shortcuts in the user's software. http://www.wats.ca/show.php?contentid=43 has a fairly comprehensive list whilst http://www.wats.ca/show.php?contentid=32 also has makes some interesting points. Since the release of Firefox 2.0, there are also problems with using numeric accesskeys on sites. http://juicystudio.com/article/firefox2-accesskeys.php My own experience and research suggests that most of the users that designers *assume* will want to use accesskeys don't bother with them. They vary too much from site to site to be really useful. Providing the tab order is intuitive, users prefer to simply tab around pages or use options within their own software (which they know far better than a random site) to jump to specific points on a page or site rather than research a whole list of new keyboard shortcuts on every site they visit. Gez Lemon and Rich Pedley developed a php AccessKeys class that allows users to define their own access keys . In theory, users could define the same subset of keys on every site that uses this approach: http://juicystudio.com/article/user-defined-accesskeys.php Gez has also since developed an .ASP version: http://juicystudio.com/article/user-defined-access-keys-aspversion.php However, I don't think either version has been around long enough, or is implemented widely enough, to indicate how many keyboard navigators actually use make use of the facility when it's offered. I know I've never bothered. :-) Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Additional space between sentences ?
on 02/11/2006 19:24 Nick Roper said the following: A client has requested that the content on their site has two spaces between the end of one sentence and the start of the next. Have they said why? Or indicated how big a unit a single space is (serious question)? If they're looking to improve readability, there are far more significant issues that they should be considering - such as what font type is being used, as well as line-height letter-spacing and word-spacing. Not to mention that actual construction of the content itself. Adding an extra space to the end of each sentence hasn't been shown to improve readability in any study I've read and might actually impede reading in the same way that justified text can do. We could do it by using non-breaking spaces, but is there a better way of achieving this - possibly with CSS? Nothing immediately springs to my mind. (X)HTML simply doesn't have a mechanisem for indicating where one sentence starts and another begins within a single paragraph. Enclose every sentence in a span and then style the span? It would be extremely tedious and would bloat the markup terribly (and unnecessarily, in my opinion). And for what benefit? Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash is more accessible than CSS?
on 30/10/2006 14:14 Rob Kirton said the following: FAO Katie Ledger I (undoubtedly along with others) found your article designing a more accessible web to be of great interest. snip If you're asking for signees to this, please add my name. Mel Pedley *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] accesibility lawsuit
on 26/10/2006 19:12 Adam Darowski said the following: I was just thinking yesterday... what is holding the open source community back from developing good screen reader software? You mean like: http://www.oatsoft.org There are a lot of smart people out there that obviously care about this. Is there some sort of hangup I don't know about? OATS is fairly new (launched May 2006) but there does seem to be a reasonable archive of software already available or under development. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] can the legend include block level elements
on 13/10/2006 19:00 Ted Drake said the following: I’ve come across a question that I can’t find an answer to. I’m building a form that has fully valid use of fieldsets, legends, labels, etc. It was suggested by a person using a screen reader that I transform the legends to headers or insert headers into the legend for the screen reader to generate the header-based navigation. I looked at the w3c site to see if the legends can include block level elements and couldn’t find the answer. Is this valid?: legendh5blah blah blah/h5/legend The HTML4 and XHTML1.0 Strict dtds both describe legend as an inline element - which would suggest that you can't use it to enclose a block level header element. Could you not precede the form with a header? Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] can the legend include block level elements
on 13/10/2006 19:29 Rob O'Rourke said the following: Ted Drake wrote: snip Is this valid?: legendh5blah blah blah/h5/legend Fraid not, I checked back to html 4 transitional using this: http://www.themaninblue.com/experiment/DTDMapper/ snip I thought the legend tag was supposed to offer some effects for screen readers when reading out the form controls. Out of curiosity do you know which screen reader it is? JAWS? I've come across some evidence that suggest that, when in Forms Mode, JAWS will only read text enclosed in form controls. Assuming that JAWS correctly identifies legend as a bona fide form control, it should render the legend before reading out the inputs. Text within the form tags that aren't enclosed in form controls, however, may be missed. I'm currently trying to find out if this is still the case with the latest version of JAWS and whether it's an issue with other screen readers. If it is, it impacts on additional text/instructions that might accompany specific inputs. If I we're you I'd just give the legends an accesskey, then you have navigation across more of browser land. How do you communicate the approprate accesskey to the user? My own research amongst keyboard navigators suggest that very few, if any, will bother to 'learn' accesskeys associated with a specific site. After all, would you? If people don't already 'know' the relevant accesskey, its usefulness becomes debatable. Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
