RE: [WSG] layout - choices?
"Could you elaborate on the misuse of s?" I can't remember any specific instances but over the last year on this list there have been numerous discussions where people were trying to shoehorn tabular data into definition lists when they clearly should have been using tables. Nick has obviously noticed the same trend. I don't have time to look them up but I'll let you know if I remember any. I'll certainly shout the next time someone does it! Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll Sent: 22 February 2007 16:24 To: wsg@webstandardsgroup.org Subject: Re: [WSG] layout - choices? [EMAIL PROTECTED] wrote: > I would disagree with the statement "It is all semantics, and will be > seen by most designers as fundamentally incorrect and misleading". I > suspect the actual figure would be nearer 0.1% of designers, although > most on this list would likely agree with the statement. > > Steve Steve, you're probably a bit nearer the mark on that one. I was talking within the context of markup nerd lists (which I occasionally forget are not all that indicative of the real world). Could you elaborate on the misuse of s? Regards, Barney *** 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] Site check andrewingram.net
It's not just blind users. In our user testing we find that new windows cause problems for many user groups, although the reasons differ. Screen magnifier users are often unaware that a new window has opened because even a relatively small window fills their entire screen area. Screen reader users are notified that a new window is opening but sometimes don't notice this warning because they are still digesting the content they were listening to on the previous page. Even a fully able user with voice recognition software repeatedly failed to notice new windows opening in some recent tests we conducted. I believe this is purely due to a lack of attention, perhaps because the voice recognition software and a large screen allow the user to adopt a more relaxed, distant viewing position. We also find that people are very selective in what they read, and often miss very clear instructions stating that new windows will open or the new page contains a different document format. I really don't know how you address this other than by not opening new windows and not using alternative document formats. With regard to the document format, all the assistive technologies mentioned above behave differently when reading PDFs, Word documents etc compared with HTML pages. Very often the users did not notice the change of format and were hence confused because the pages did not respond as expected. By all means provide these formats for downloading and distribution but wherever possible it is best to keep to HTML. Steve Green Director Test Partners Ltd / First Accessibility .testpartners.co.uk www.accessibility.co.uk _ From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 19 February 2007 12:50 To: wsg@webstandardsgroup.org Subject: RE: [WSG] Site check andrewingram.net Lisa, For a blind user, it is very annoying for a new window to open, breaking the back button. If you want further evidence, there is plenty out there, and pretty much all of it says "don't use new windows" Mike _ From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of lisa fox Sent: Sunday, February 18, 2007 3:34 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Site check andrewingram.net Tim, Agreed. However, from a user-friendly perspective, it is very annoying to close a window and realise that you have lost where you were. This is where you make the decision on the purpose of the website, whether it is purely to display that you can comply with strict or whether it is for the user. Lisa On 2/18/07, Tim <[EMAIL PROTECTED]> wrote: Lisa, You can't open new windows and still have a Strict DOCTYPE as Andrew has! Personally I think pdf are annoying and would I prefer to see the content in a webpage, maybe an option to download the pdf. Tim On 18/02/2007, at 2:04 PM, lisa fox wrote: > Hi Andrew > You are better to open the pdf and Word document in a new window. > Most viewers would click on the link,the pdf/Word opens in the same > browser window. They would finish reading and out of habit close the > window forgetting that it is the same window. If the documentsopen > in a new window the viewer can close the window and remain on your > site. > > Lisa > > > > On 2/18/07, Andrew Ingram <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: Hey all, >> >> It's been a long week, but i've got my basic site template integrated >> with Expression Engine (from scratch, in my wisdom I decided it would >> be >> a good idea to delete all the default templates and build everything >> from nothing :/) >> >> So I invite you all to check for accessibility, semantics and all that >> jazz.I welcome any suggestions provided that the suggestion isn't to >> switch to a liquid or elastic layout :) >> >> Basically, anything you can think of (especially things that are an >> easy >> fix) would be most welcome. >> >> http://www.andrewingram.net/ >> >> Thanks, >> Andrew Ingram >> >> >> *** >> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> Help: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> *** >> > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: [EMAIL PROTECTED] > *** The Editor Heretic Press http://www.hereticpr
RE: [WSG] Usability Questions for Quicktime
It may just be that our customers are not very good designers but many of the Flash-based multimedia projects we have tested have had problems with resource utilisation. Often the video will use 2 or 3 times as much CPU and memory when it is embedded in Flash compared with playing it in a media player. I have seen this kill reasonable spec machines like a 2GHz P4 when the original video would play ok on a machine half that speed. I just finished such a project today. One video had been compressed to three different levels to allow it to be streamed at different rates. All three videos used the same CPU and memory even though the file sizes varied by a factor of 4 to 1. It means that people with different connection speeds can make an appropriate choice but people with low-specification hardware (1GHz PIII and below in this case) cannot. We are not designers, just testers, so I don't know if there is a simple solution to this. However, we work for a lot of clever people and they often revert to a non-Flash solution. You also need to be careful how you embed your Flash content because some techniques (I believe Satay is one) are not accessible to screen readers. At this very moment I am testing a site where this happens. Unfortunately a very loud Flash-based audio track starts when the page loads and the button for silencing it is not accessible because JAWS does not even recognise that the page contains a Flash movie. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Jan Brasna Sent: 05 February 2007 23:47 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Usability Questions for Quicktime > 1. What is the best way to "hide" the movie from browsers that don't > support quicktime (or from users who don't want to download quicktime)? To use an UFO/SWFObject alternative for QT, or Satay-like QT alternative w/ fallbacks. > 2. Is there a different file format which is more universal? Flash - FLV. Great compression effectiveness, 97% reach (compared to ca. 66% of QT), pretty much platform independent (sans non-x86 or x64 unix). -- Jan Brasna :: www.alphanumeric.cz | www.janbrasna.com | www.wdnews.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: Does a Navigation Block *really* need to be identified as such? (was RE: [WSG] Title attributes)
John, I would agree that there is little or no value in providing a heading for a single list. However, we often work on sites that have thousands of pages, that have at least two levels of navigation menus and sometimes three. There are often other lists at the top of the page, such as to the Sitemap, A-Z List, Accessibility Options etc. These lists are usually styled visually so it is obvious what each list is, but it can be difficult to differentiate between all these lists when they are linearised in a non-CSS user agent such as Lynx, Webbie or some mobile devices. Rather than search for a specific link (assuming you know what you are looking for), it is easier to scan the page for headings, which most of these user agents style differently from the list items. I have to say that my opinion is based mostly on my experience of testing with mobile devices and Lynx rather than testing with other users, although some screen reader users have commented positively on the provision of these headings. When a screen reader user is navigating within a page, they benefit from having landmarks like this. I have had no adverse comments on the hidden headings, but they would not have been visible to most of the users we have tested with. I really don't understand your objection and certainly don't see it as 'segregation'. We do all kinds of things to benefit specific user groups, and this is just another. Steve - Steve, Is this based on your user-testing feedback (no downside)? My only concern is that we're hiding the heading via CSS for the majority of "mainstream" users, yet leaving it in for "the others" - I find this hard to accept. This segregation feels like a downside to me... Who here really has a problem understanding the following: SUPER-DUPER WEB SITE * Home * About this Site * Frequently Asked Questions * Contact Us * Site Map ...? I suggest that even the newest beginner, sighted or otherwise, will quickly and easily grasp both the concept and the function of that list - it is, after all, the foundation of the web itself - click on those link-words and that's where you go. Screen readers in particular will announce each as a link, whereas un-styled sites/user-agents will also indicate that they are links (blue underline, etc.). Do we really need to hit them over the head harder than that? As I was thinking about this, it occurred to me that one person who might also have some insight into this would be Jonathan Chetwynd of Peepo (http://www.peepo.com/), who has done some extensive and valuable work with Downs Syndrome users, and has a very clear grasp of users with severely cognitive impairments. Yet a check of his site (which is essentially a list of navigation links) shows that he has not bothered announcing that his list of navigation links is a list of navigation links. (Even just typing that out makes it seem kind of redundant). To be sure, a consistent placement and treatment of site navigation on each site is important, perhaps even critical. As Roger's OzWai presentation[1] alluded to however, even here the "location" of the primary navigation block was less critical than the consistency - that said it also left me with the feeling that all things being equal, newer, less experienced users showed a slight preference for site navigation at the "top" of the document. (And Roger's testing panel was very small). With this in mind, and convention being what it is, it would seem (to me) that for the majority of users, the initial list of links at the top of any page are used for navigation - we don't need to keep telling them that (after all, if we include it on the first page, it will be on *every* page, and I'm sure your non-sighted userbase have comments about overt verbosity...) I think at this time we are still very much in the realm of *opinion*, and I respect that many in the field of web accessibility and web standards are well meaning, well versed in the "issues", and want to do everything they can to improve and maximize the user-experience for all; but I also honestly think we need imperial data and proof that this *is* the best practice before we start floating it as such - I for one remain skeptical. JF [1] If you missed the original link: http://www.usability.com.au/resources/ozewai2005/ *** 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] JAWS Screen Reader Demo
We are doing another free JAWS screen reader demo (our 7th!) on the afternoon of Monday 19 February 2007. A couple of the places are already booked but there are still six left. We limit the demo to 8 people so book early. The demo starts at 1:30pm and a free light buffet is available from 12:30 for those who want to come early. We are scheduled to finish at 5:30pm but you are welcome to stay afterwards to get some hands-on experience or look at some more websites. If anyone would like to attend this demo or a future one please fill in the form at http://www.accessibility.co.uk/free_jaws_demo.htm. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Title attributes
The use of hidden headings for navigation is of benefit to anyone whose user agent does not support CSS, not just screen reader users. We are seeing an increasing number of sites built that way and there isn't a downside that I can think of so perhaps it should become standard practice. Screen readers do not read 'title' attributes by default. You can configure some to read 'title' attributes instead of the on-page text but no one is going to have that as a permanent setting. You can also read the 'title' attribute for a specific element but that presupposes the user knows which elements have 'title' attributes. Tooltips of any kind can be a nuisance for screen magnifier users because even a small one can obscure a large proportion of the screen at modest magnification levels. It is even worse when the tooltip is caused by the 'title' attribute for a structural element such as a paragraph or a div because the user does not know where to move the mouse to get rid of it. It may not even be possible if the element fills the entire screen. For this reason I would not recommend using a 'title' attribute for a list. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Antonios Sarhanis Sent: 24 January 2007 23:00 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Title attributes I give headings to my navigation, as well as other areas on the page, but the headings are hidden (position: absolute; left: -100em) so that they can be read by a screen reader. >From what I've read, title attributes should only be sparingly and in special cases where more information might be helpful rather than annoying. Having the title say exactly what a piece of text says is completely useless, and having the title say something slightly different to what a piece of text says only makes things annoying for users with a screen reader that might have to read both instances of the very similar text. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] IE7/CSS issues on a site
It is not displaying correctly in IE7. The tabs are too low so only half the text is visible. I have sent you a screenshot. Steve _ From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of GALLAGHER Kevin S Sent: 22 January 2007 18:59 To: wsg@webstandardsgroup.org Subject: [WSG] IE7/CSS issues on a site I have a site which seems to work fine in Firefox and IE6 but heard (I don't have IE7) that the navigation is not displaying correctly. Can someone with IE7 confirm this or not? http://www.snagedu.com/ Thanks, Kevin S Gallagher *** 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] Logo and H1's
I bought your book - isn't that enough? And if you make the 300-mile round trip to the demo I'll even buy lunch. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 13 January 2007 19:53 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Logo and H1's Steve Green wrote: > Which leads perfectly into a plug for our free JAWS screen reader demos. Pssst...where's my agreed commission? ;) 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/ __ *** 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] Logo and H1's
Patrick wrote
"In general terms, what I'm trying to convey here is: it's easy to pick up a
screenreader as a sighted user, do some testing, and come to some
conclusions, all with the right intentions of course, like "oh, this must be
annoying for those users"...but, not being a blind user who uses that
technology day in, day out, it's also possible to draw some erroneous
conclusions, or to seek absolute, black and white maxims ("this should never
be done") where there are really just opinions, personal preferences, and
lots of shades of gray."
Which leads perfectly into a plug for our free JAWS screen reader demos. One
of our blind testers talks about how blind people visualise web pages and
navigate through them. We then have some practical examples where he visits
sites he has not seen before so you see his approach to browsing, the
problems he encounters and how he overcomes them (if he can!). The next one
on Monday is fully booked (maybe I can squeeze in one more) but there will
be another in February. You can register at
www.accessibility.co.uk/free_jaws_demo.htm
Steve Green
Director
Test Partners Ltd / First Accessibility
www.testpartners.co.uk
www.accessibility.co.uk
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Free Screen Readers (was: Logo and H1's)
I am currently doing a review of all the screen readers that are available. This will take a few months because there are more than you may imagine. Here are some initial observations: JAWS - Eye wateringly expensive but it's the best there is despite having plenty of shortcomings. Has at least 50% market share. WindowEyes - Expensive but pretty good. Better than JAWS for some applications but not others. Not much different for web browsing. HAL and SuperNova - Similar to WindowEyes. Those three are serious professional products that work to varying degrees with Windows and most applications. Note that you can not use the trial versions for testing. Read the license terms. The trial version is to help you make a purchasing decision. It is not a convenient loophole for people who cannot or do not want to buy it. IBM Home Page Reader - Little used and no longer supported. I don't know much about it. Virgo - I only recently found out about this screen reader and have not used it yet. Thunder - I am not very familiar with this but one of our blind trainers has evaluated it and is not very impressed. It has potential but the creators need funding to improve it. The creators say it is not intended for reading web pages directly. You are supposed to use it in conjunction with Webbie, which creates a linearised version of the page but also removes semantic structure. VoiceOver - Comes with Mac OS X 10.4 and above. All OS X applications have some level of support. I am pretty unimpressed because for instance it does not announce the presence of any semantic structure such as headings and lists, and all keyboard controls require 3 keys, which gets tiring. It has a tiny but strong following but these appear to be typical Apple fanboys who would never admit it was less than perfect even if it crashed every two minutes. Also they have few alternatives. Narrator - Built into Windows 2000 and XP and works to some extent with all applications. Only really any use for getting you out of trouble if your primary screen reader fails. On web pages it only reads the links. Fire Vox - Free extension for Firefox. I have tested this extensively and corresponded with its creator, who has been very helpful. However, it is really just a pet project and it is a long way short of being usable as a primary screen reader. The user experience is nothing like JAWS. If you're looking for a free screen reader it's better than nothing but don't imagine you're getting the equivalent of one of the big 3. Fangs - Don't bother. It claims to produce a text version of what JAWS would read but there are some significant shortcomings. Firstly the behaviour of JAWS varies from version to version; which version is it emulating? The biggest issue is that it doesn't remotely give you any idea of the user experience. Assessing the comprehensibility of a page involves much more than simply knowing what words will be spoken. It would help if the text was laid out in an approximation of the mental model the user will build but frankly it's not worth the trouble. The problem with most of the cheap or free screen readers is that they don't convey semantic structure and the user experience is nothing like the big 3 professional products. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Smith Sent: 12 January 2007 22:36 To: wsg@webstandardsgroup.org Subject: [WSG] Free Screen Readers (was: Logo and H1's) Quoth Rob O'Rourke at 01/13/07 08:25... > I've not managed to get a screen-reader working very well for testing > so far, does anyone know of one (preferably free) that provides a > fairly typical screen reader experience? > > JAWS is a bit out of my price range. You could try the Fangs[1] extension for Firefox. Fangs renders the page as text, but the text that would (probably) be spoken by Jaws. I have never managed to get it working myself, but it may be worth a look. Cheers M References 1 - <http://www.standards-schmandards.com/projects/fangs> -- Matthew Smith IT Consultancy & Web Application Development Business: http://www.kbc.net.au/ Personal: http://www.smiffysplace.com/ LinkedIn: http://www.linkedin.com/in/smiffy *** 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] Re: usage of fieldset
It actually reads fine with a screen reader - that was the first thing I did when I first came across it. The legend just appears to be another paragraph and the user is totally unaware of the inappropriate use of the fieldset elements. It would obviously be better to use header elements but it's actually not that bad. In fact I can't think of any problems it would cause for any user group or user agent. At least it doesn't add a load of verbiage like some nasty coding methods. I came across a site where they wanted to indent alternate paragraphs by about 100 pixels so they put those paragraphs inside three nested blockquotes. That resulted in JAWS reading "blockquote blockquote blockquote blah blah blah blah blockquote end blockquote end blockquote end". Now that is nasty. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Frank Palinkas Sent: 12 January 2007 15:43 To: wsg@webstandardsgroup.org Subject: RE: [WSG] Re: usage of fieldset Hi Steve, Yep, I've seen it also. Pity the visually challenged user with a screen reader trying to figure out what's going on. Frank -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Steve Green Sent: Friday, 12 January, 2007 17:28 PM To: wsg@webstandardsgroup.org Subject: RE: [WSG] Re: usage of fieldset I have seen several sites that have done this, presumably for the visual effect of having a border around each subsection of content; some browsers will give that border round corners. Of course the same effect can be achieved with the correct use of CSS but maybe they just thought this way is easier. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll Sent: 12 January 2007 14:59 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Re: usage of fieldset Mihael Zadravec wrote: > Hi! > > What would be your reaction, if you'd see someone using for > something else than containing forms? > > eg. something like... > > > Some tite here > > This is some content. > > > > cya! > Mihael It's incorrect and pointless. Why would anyone want to do such a thing? Regards, Barney *** 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] *** *** 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] Re: usage of fieldset
I have seen several sites that have done this, presumably for the visual effect of having a border around each subsection of content; some browsers will give that border round corners. Of course the same effect can be achieved with the correct use of CSS but maybe they just thought this way is easier. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll Sent: 12 January 2007 14:59 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Re: usage of fieldset Mihael Zadravec wrote: > Hi! > > What would be your reaction, if you'd see someone using for > something else than containing forms? > > eg. something like... > > > Some tite here > > This is some content. > > > > cya! > Mihael It's incorrect and pointless. Why would anyone want to do such a thing? Regards, Barney *** 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] my world, my country.. :(
Audio opens up a new can of worms. It certainly should not start automatically because that causes problems for several user groups, not just those with disabilities. It could benefit some users but you shouldn't implement it in a way that is to the detriment of others. Some blind people use Braille displays rather than screen readers but this is not common. I don't see the benefit of adding audio unless the Flash content is 100% accessible, in which case it ought not to be necessary. Navigating with a screen reader or Braille device is a lot slower than using a graphical browser, so users don't want to spend time doing anything that isn't really necessary. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Rob O'Rourke Sent: 10 January 2007 17:27 To: wsg@webstandardsgroup.org Subject: Re: [WSG] my world, my country.. :( Hassan Schroeder wrote: > Steve Green wrote: > >> We do a lot of user testing with screen reader users,... >> > > >> Also Flash movies are made in layers. >> > > Have you tested any (non-timelined) Flex-based sites or apps? > > Just my two pence but I think what you really need to do is add an audio layer to that flash site. As an example one of the sites we host (its not at all accessible code-wise) has audio to say hello and indicate what you can do on a page. I think similar use of audio on that site to read it from the flash would be a nice touch. Then it'd be accessible to blind users who don't have a screenreader too (...they must exist) Rob O *** 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] my world, my country.. :(
We have tested many Flex-based applications, mostly for e-learning, and the same issues apply. If anything Flex-based applications are worse because they tend to be more interactive. Designers often create their own form controls so they can style them however they want, and these are almost never accessible. Furthermore, Flex-based applications are often accesible to such an extent that the screen reader user thinks they are working correctly even though some static and/or dynamic content is not accessible or is not presented correctly. This can cause frustration and waste time, and it would sometimes be preferable if the application presented a barrier from the outset rather than sucker the user into thinking it works when it actually doesn't. I think we're getting way off topic here so anyone who wants to discuss this further should contact me off-list. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Hassan Schroeder Sent: 10 January 2007 15:54 To: wsg@webstandardsgroup.org Subject: Re: [WSG] my world, my country.. :( Steve Green wrote: > We do a lot of user testing with screen reader users,... > Also Flash movies are made in layers. Have you tested any (non-timelined) Flex-based sites or apps? -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com opinion: webtuitive.blogspot.com dream. code. *** 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] my world, my country.. :(
We do a lot of user testing with screen reader users, and this is the basis for most of my contributions to this list. Flash support has increased over the last few years so the user experience depends both on the make of screen reader and the version. The user experience can be good if the designer has taken the appropriate steps to label buttons and correct the tab sequence. However, this does not happen by default, and most developers do not take the necessary measures so links are often read as "button one", "button two" etc. Often some content is not read, some links are not on the tab sequence and some events are not exposed to the screen reader. Also Flash movies are made in layers. It is common for them to be designed such that only the top layer is clickable at certain times (e.g. modal dialogs), but screen readers can often programmatically access content in layers that should not be accessible. This can be extremely confusing. The bottom line is that Flash can be reasonably accessible but usually isn't and it can never approach the accessibility of HTML. Screen readers are available at most price points from free up to nearly $2000. I am currently evaluating several to determine how they differ, and have nearly finished evaluating Fire Vox, which is a free extension for Firefox. Surprisingly, the user experience is very different from JAWS and in my opinion it needs a lot of work to be considered a viable option. In fact it makes you appreciate how good JAWS is. I will be publishing the results on our website but that won't be for a couple of months yet. Steve _ From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Mihael Zadravec Sent: 10 January 2007 07:52 To: wsg@webstandardsgroup.org Subject: Re: [WSG] my world, my country.. :( Hello Steve! Do you have any information about screen reader users expirience with flash elements like navigation or others? Is the flash content ok with them or is it not? I also think that 1,000 $ is too much for a software like screen reader... Becasue of its nature, this software should be more reachable to its audience.. Mihael *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] my world, my country.. :(
The Flash movie is accessible with JAWS 7.0 although it does not pronounce the first letter of the words 'Center', 'Slabovidnih' and 'Starejsih'. I guess these must be images. When the page loads JAWS says "page has no links" but this is because it is only looking at the HTML content. When you navigate through the Flash content it reads both links and they both work. On the next page none of the graphics in the menu has an 'alt' attribute. JAWS therefore reads the folder name and the filename without the extension. The filenames are very similar to the text in the graphics so this may be comprehensible. I can't tell because my Slovenian is a bit rusty and JAWS is reading it in American. JAWS does not have a Slovenian phoneme set so it wouldn't pronounce the words correctly even if the 'language' attribute was specified, which it isn't. Does anyone know what screen reader Slovenians use? The frames and tables have no impact on screen reader users. In fact the use of frames can help the user understand the structure of the page, particularly if there is little or no semantic structure, as is the case with this site. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Paul Novitski Sent: 09 January 2007 19:06 To: wsg@webstandardsgroup.org Subject: Re: [WSG] my world, my country.. :( At 1/9/2007 10:15 AM, Mihael Zadravec wrote: >This is realy sad... but this is the website of a Blind peopele >comunnity Škofja Loka from Slovenija (where I live, but in >Ljubljana...) > >Center slepih in slabovidnih Škofja Loka ><http://www.css-sl.si/>http://www.css-sl.si/ > >any comments on the code, usabillity and accessability issues? I don't have a screen-reader and can't determine whether the Flash application is in any way accessible, but on the surface the home page is wholly INaccessible as it doesn't contain any text or even any link to text. The sub-pages I looked at are frame-based and table-based which also present accessibility issues. It surprises me that anyone would design a website for a blind community that can't be easily read by blind people. Now *that* is sad. Regards, Paul *** 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] display:none; property and screenreaders
I've come a bit late to this thread but I would like to make the following observations regarding previous comments: 1. Screen readers ignore comments. 2. The most advanced screen readers can access Flash content but this is very unreliable. Sometimes they cannot access any of the content, sometimes they can access only some parts, sometimes they can read the text content but cannot operate the links, sometimes the tab sequence is totally wrong. Some Flash content cannot be accessed using keyboard controls regardless of whether a screen reader is used. Occasionally screen readers can actually access all the content and functionality but this is not common. 3. I have come across several cases where it was desirable to 'hide' content using negative left margin. The provision of structural information has already been mentioned. Also it can be useful for providing alternate content for pages containing multimedia or complex graphical information. Of course this text equivalent could be provided on a separate page, but hiding it on the same page provides a more seamless experience. 4. I am not in favour of using graphics for navigation because it is not possible to resize the text or change the colours. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Kay Smoljak Sent: 09 January 2007 13:40 To: wsg@webstandardsgroup.org Subject: Re: [WSG] display:none; property and screenreaders On 1/9/07, David Dorward <[EMAIL PROTECTED]> wrote: > I'm very much in favour of text based navigation - but if an author is > going to go with an image based design, then the use of elements > with alt text is the sane approach. But the current web is not solely a text-based medium. Maximum accessibility for both assistive technology and search engines/alternative user agents means that images that are purely presentational should not be in the markup - the presentation layer is where they belong. So sane or not, hiding or replacing text with CSS is effective, as Russ's research proves, and popular, as the current crop of showcase CSS sites demonstrate. It's certainly the approach that I favour. -- Kay Smoljak business: www.cleverstarfish.com standards: kay.zombiecoder.com coldfusion: kay.smoljak.com personal: goatlady.wordpress.com *** 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] Does this hurt accessibility
I expect this will degrade the experience for anyone using a screen magnifier. We find that even relatively small tooltips hide a large proportion of the viewport when using magnification levels above x3, and these popups are a lot bigger. A magnifier user will typically move around the page by dragging the mouse to one edge of the screen (they only use the scrollbars when they reach the edge of the page), so they will often hover over links unintentionally, particularly graphical links since they are typically bigger than text links. I think it would be quite unpleasant to have these things pop up all the time, especially as they may entirely fill the viewport. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of John S. Britsios Sent: 05 January 2007 04:14 To: wsg@webstandardsgroup.org Subject: [WSG] Does this hurt accessibility Dear members, We are thinking of implementing this service http://www.snap.com/about/spa1A.php on our web site, and our question is, if you think that it can hurt our site accessibility in someway? We sure will implement the tag if that solves the problem. Thanks a lot for your kind suppport. Best wishes, John -- John S. Britsios Web Architect & Business Consultant Webnauts Net & SEO Workers (Main Office) Koblenzer Str. 37A D-33613 Bielefeld Webnauts Net & SEO Workers (U.S. Office) 5 Ivanhoe Drive Urbana IL 61802 http://www.webnauts.net http://www.seoworkers.com *** 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] New UK rules
The full story is here - http://out-law.com/page-7594 Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Frances Berriman Sent: 03 January 2007 23:42 To: wsg@webstandardsgroup.org Subject: Re: [WSG] New UK rules On 03/01/07, Designer <[EMAIL PROTECTED]> wrote: > > My service provider sent the following out in the latest newsletter. I > was not aware of this, so in case any of you weren't aware either, I > include it here: > > REGULATION ISSUE > From today, companies in the UK must include certain information on > their Web sites and in their e-mail footers or they will breach the > Companies Act and risk a fine. The minimum information needed on any > business site includes the name, geographic address and e-mail address > of the business and the legal name of the organisation with which the > customer is contracting. Also, if the business is a company, the > registered office address and the registration number. If the business > is a member of a trade or professional association, membership > details, including any registration number, should be provided. If the > business has a VAT number, it should be stated - even if the Web site > is not being used for e-commerce transactions. Prices on the site must > be clear and unambiguous and state whether they include tax and delivery costs. > > Bob > > www.gwelanmor-internet.co.uk > Interesting. Did they say where this regulation comes from? A document or such? -- Frances Berriman http://fberriman.com *** 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] page loads in safari and then jumps to the middle
No, it's ok now. My last post was before you removed the objects. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Rob O'Rourke Sent: 03 November 2006 20:52 To: wsg@webstandardsgroup.org Subject: Re: [WSG] page loads in safari and then jumps to the middle Steve Green wrote: > It seems better but when I hover over a link it still reloads, jumps > down to the Cocktail Bartender subheading then up to the Web Designer > subheading. At least it doesn't bounce up and down continuously and crash the browser. > > Steve > > > Is that even with the objects removed? If so I'll take out those links altogether and get on the uF-discuss list about it. Cheers, Rob O *** 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] page loads in safari and then jumps to the middle
It seems better but when I hover over a link it still reloads, jumps down to the Cocktail Bartender subheading then up to the Web Designer subheading. At least it doesn't bounce up and down continuously and crash the browser. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Rob O'Rourke Sent: 03 November 2006 19:13 To: wsg@webstandardsgroup.org Subject: Re: [WSG] page loads in safari and then jumps to the middle Steve Green wrote: > Wow, it's even worse now (or maybe it would have done this before but > I never tried it). > > If I hover the mouse over a link and leave it there, the page > continuously reloads and it jumps up and down between the Cocktail > Bartender and Web Designer subheadings. It gets slower and slower till > the 'beachball of death' appears and I have to force quit the browser. > > We've seen some weird stuff in our time but nothing quite like this. > > Steve > > > :$ poop... I don't think on online cv that breaks safari is going to get me very far... I've stripped out the CSS now... any joy? It seems to work ok in swift except it loads up with the high contrast large print css for some reason. Rob O *** 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] page loads in safari and then jumps to the middle
Wow, it's even worse now (or maybe it would have done this before but I never tried it). If I hover the mouse over a link and leave it there, the page continuously reloads and it jumps up and down between the Cocktail Bartender and Web Designer subheadings. It gets slower and slower till the 'beachball of death' appears and I have to force quit the browser. We've seen some weird stuff in our time but nothing quite like this. Steve -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Rob O'Rourke Sent: 03 November 2006 17:37 To: wsg@webstandardsgroup.org Subject: Re: [WSG] page loads in safari and then jumps to the middle Steve Green wrote: > I'm running Safari 2.0 and it does jump. However, it does not jump > immediately. When you hover over a link the page reloads and this is > when it jumps (not always to the same place). The same happens if you > press the Tab key after the page loads. It does this even if JavaScript is turned off. > Sorry, I have no idea why it's doing it. > > Thanks for confirming that Steve, I've taken all the javascript out because its kinda pointless in this instance. Can you check if the same happens on this page please?: http://robert.o-rourke.org/undex.php I've removed the anchor link which might have been the reason for it... guess it's a process of elimination from here on. Cheers, Rob O *** 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] page loads in safari and then jumps to the middle
I'm running Safari 2.0 and it does jump. However, it does not jump immediately. When you hover over a link the page reloads and this is when it jumps (not always to the same place). The same happens if you press the Tab key after the page loads. It does this even if JavaScript is turned off. Sorry, I have no idea why it's doing it. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Rob O'Rourke Sent: 03 November 2006 16:08 To: wsg@webstandardsgroup.org Subject: [WSG] page loads in safari and then jumps to the middle Hello there, I've been putting my CV together but I don't have a mac for testing, a friend of mine who does said that when the page loads up in safari it immediately jumps to where it says 'Web designer and developer'. I'm stumped as to what might be causing it. The page in question is at http://robert.o-rourke.org Anyone run into a similar problem before? I'm planning to make the cut-out thing smaller, I was developing the concept and haven't re-done any graphics yet. Cheers, Rob O *** 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] Articles/reasearch/experience of screen readers
A 'go to text version' link certainly won't hurt, but our experience of user testing is that they are rarely used. In fact we did a test project last week where the site had a text version, an audio version and a built-in magnifier, but only one of the three users (who was a screen reader user) even noticed any of them. However, despite having some difficulties with the site he never tried the text-only version. Maybe this is because in the past text-only versions were maintained (or not) separately and often had outdated or incomplete content. Obviously it is possible to generate both versions from the same content but few sites do this. We also came across a site that had no fewer that six 'skip to' links such as 'skip to main navigation', 'skip to sub navigation', 'skip to main content' etc. The whole thing was so verbose that they really needed a 'skip past all these skip links' link. The point being that screen reader users benefit from pages being as terse as possible (i.e. less to remember), and that sometimes they are hindered by features that have been added to help them. With regard to 'title' attributes, by default these are not read by most screen readers. Some have an option that allows the user to read them but that's little use because the user has no way of knowing if an element has a 'title' attribute except by trial and error, and it's too much hard work to keep checking. My email program mangled my previous emails today, so in case anyone missed it, we're running a free JAWS demo on 27 November. Full details and booking form at www.accessibility.co.uk/free_jaws_demo.htm. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Sent: 02 November 2006 23:28 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Articles/reasearch/experience of screen readers I have been following this with great interest. What I have been considering (I know its been covered before) is putting a link at the top of the page, go to text version Go to menu I would think that screen reader users would find that a good addition to be able to read an article in text only, and a shortcut to scan articles which also have brief title tags in addition to descriptive titles. In my design content comes first already... Bruce Prochnau BKDesign Solutions *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Support for IE5/Mac? (was Browser stats)
I would hardly call OSX an 'upgrade' - it's a major investment. It's not just the £100 or so for the OS, it's the cost of all the new applications like an office suite and all the other stuff you need plus the installation time and hassle of migrating email accounts etc. For testing purposes we run OS X 10.2 on a 400MHz G3 iMac DV and it's pretty slow. You can only install Safari 1.0 on this but at least you can install Firefox or Opera. You can't install newer versions of OS X on it because the required firmware upgrade kills the video card. I don't have current figure for OS9 usage but in June 2004 (i.e. 3 years after OS X launched) Steve Jobs announced that 50% of the 24 million Mac users were now using OS X. That means 50% were still on OS9 or earlier. In the developed world we're used to having pretty up to date kit but don't forget that a large proportion of the world's population can't afford this and still use much older kit, often machines that have been discarded here precisely because the software cannot be upgraded. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lazar Sent: 02 August 2006 02:02 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Support for IE5/Mac? (was Browser stats) Out of interest, does anyone know how many OS 9 users are still out there? Nick. On 2 Aug 2006, at 10:55, Nick Gleitzman wrote: > Steve Green wrote: > >> One reason for continuing to support IE5/Mac is that OS9 users can't >> upgrade to anything better. > > Of course they can upgrade - to OSX. OS9 itself is, if not officially > obsolete, shall we say deprecated? Macs haven't been made to boot into > 9 for some time now. OSX *will* run on most Macs (albeit slowly) > unless they're *really* old and underpowered... > > Reality check: it's 2001. The world moves on, and I think that > delivering a typographically styled but layout deficient version of a > site (with a polite explanation of why the presentation is > limited) to users of obsolete browsers is far better than giving them > a site that's broken, especially if it's preventing usability. > It can only help to weed these browseers out of the scene, eventually > - and then we won't have to worry about them at all! > > N > ___ > Omnivision. Websight. > http://www.omnivision.com.au/ > > > > ** > 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 ** ** 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] Support for IE5/Mac? (was Browser stats)
One reason for continuing to support IE5/Mac is that OS9 users can't upgrade to anything better. Neither Firefox nor Safari is available for that platform. Netscape 6.x is available but has its own problems. They can't even install an Opera version newer than 6.0. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Nick Gleitzman Sent: 02 August 2006 00:26 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Support for IE5/Mac? (was Browser stats) Paul Collins wrote: > so when clients ask me what to build for I can justify building for > IE5 Mac. Given that IE5/Mac is now officially obsolete, why not group it with other dinosaurs (NN4.x et al) with flaky CSS support and filter your CSS delivery so that browser only receives a stylesheet for nice typographic presentation, but not the full layout? This is what I've started doing... Generate the CSS for typography, bg colour/s, etc (e.g. basic.css) and a separate file for (e.g.) layout.css. Use the Tantek hack in the call for the second file in the of your (X)HTML file, thus: /*\*/@import "inc/layout.css";/**/ and voila, IE5/Mac only recognises the first file. It saves hours of trial and error trying to get layouts to work in IE5M as they do in compliant browsers, and keeps your layout.css file clear of multiple instances of the Tantek hack. And as a bonus, because of the media attributes, your print styles are taken care of as well... N ___ Omnivision. Websight. http://www.omnivision.com.au/ ** 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] Browser stats
That argument may seem reasonable but it is flawed. If users with particular user agents can't use your site or find it difficult to use then they are less likely to return. Your stats will then show a low number for these users. You might conclude that the low number means you don't need to bother fixing the site to cater for these users but in fact the exact opposite is true. Steve From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Seb FrostSent: 01 August 2006 14:20To: wsg@webstandardsgroup.orgSubject: Re: [WSG] Browser stats The only way to get accurate statistics is to gather your own, on each individual site. Then you're guaranteed a relevant sample. If you look at statistics of any other site, no matter what they might claim, you're not getting the information you need! Make the site, put it up, check your stats, make any changes you deem necessary. If it's a design question then go for 800x600 for now, and change later if/when you decide you have enough 1024x768+ users. - seb On 01/08/06, Paul Collins <[EMAIL PROTECTED]> wrote: Hi all, Just wondered if anyone has a good resource for Browser stats. Currently I've got a few but most get their stats from visitors to the site which can be a bit biased. Currently I've got http://www.upsdell.com/BrowserNews/stat.htm http://www.thecounter.com/stats/2006/July/browser.php Anyone got better?! Cheers**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.cfmfor 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] Browser stats
There is a section about statistics including a bunch of links on my Squidoo lens at www.squidoo.com/browser_compatibility. Steve GreenDirectorTest Partners Ltd / First Accessibilitywww.testpartners.co.ukwww.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Paul CollinsSent: 01 August 2006 13:00To: wsg@webstandardsgroup.orgSubject: [WSG] Browser stats Hi all, Just wondered if anyone has a good resource for Browser stats. Currently I've got a few but most get their stats from visitors to the site which can be a bit biased. Currently I've got http://www.upsdell.com/BrowserNews/stat.htm http://www.thecounter.com/stats/2006/July/browser.php Anyone got better?! Cheers**The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor 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] WCAG 1.0 and 'Until user agents...'
I disagree with Patrick's assessment on several points: 10.2 - Some user agents such as Lynx linearise the page but do not support elements so it is still important to correctly position the labels. 1.5 - Some users are not able to use image maps for a variety of reasons so I would always provide redundant text links. One reason is that it is often difficult to see which area of the map has focus when using keyboard navigation. In our experience image maps are no obstacle for screen reader users but they are more of a problem for users of screen magnifiers because they often require both vertical and horizontal scrolling. Also the label for each area is often provided by means of a tooltip because the areas are too small for a text label, and the tooltip is often not fully visible without scrolling. For these users a combobox is far more accessible. 10.3 - One of my testers still uses ZoomText 7, in which the Doc Reader function does do a screen scrape and therefore reads across columns. Version 9 does not do this but there will be plenty of people still using earlier versions. 10.4 - Totally agree. Default placeholding text does more harm than good. All this raises an interesting issue. Does "until user agents..." mean "until some user agents..." or "until most user agents..." or "until all user agents..."? And how would we know when any of these criteria are met, because I am not aware of any statistics for the usage of the various makes and versions of user agent or AT? With the exception of 10.3 all of these checkpoints are easily implemented at little or no cost and they have little or no impact on the design so I generally don't ignore any of them except 10.3. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 24 July 2006 09:13 To: wsg@webstandardsgroup.org Subject: Re: [WSG] WCAG 1.0 and 'Until user agents...' Lindsay Evans wrote: > I'm in the process of defining accessibility guidelines for a new > site, and am thinking it would be helpful to eliminate certain WCAG > checkpoints that are no longer relevant and could possibly lead to > usability problems if followed to the letter Here are my thoughts on which WCAG 1.0 checkpoints can be knowingly ignored: 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. (though it's still best practice from a usability point of view) 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. (as long as there is at least a single space, and the styling of your page is clear enough - e.g. maybe a bit of extra horizontal padding for inline links) 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. (as far as I know, all modern user agents should cope fine with properly marked up client-side image map...as long as you provide ALTs for each AREA) 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. (since most AT looks to the document source, rather than simply visually scraping the screen, this shouldn't cause any more issues) 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. (apart from old braillers, this is not an issue anymore; in fact, having place-holding content can be a usability issue, as users need to go the extra step of first deleting the default content) Unfortunately I don't have an exact list showing what current UAs/ATs support...this is mainly based on empirical evidence, discussions with users of specific ATs, and a bit of gut instinct. Patrick -- 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] email stripping out the css from tables?
Last year the W2K News email newsletter changed from HTML to text and there was a massive backlash from the readers, after which the publishers made the format optional. After this cock up they polled the readership for their preferences and the majority wanted HTML, but unfortunately I can't find the poll results. I don't have any figures for marketing campaigns but it is my preference to receive some types of email (such as newsletters and promotions) from trusted sources in HTML format. Steve GreenDirectorTest Partners Ltd / First Accessibilitywww.testpartners.co.ukwww.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of pdr ListsSent: 03 July 2006 12:37To: wsg@webstandardsgroup.orgSubject: Re: [WSG] email stripping out the css from tables? On 03/07/2006, at 7:44 PM, Michael Persson wrote: I'd agree from a personal perspective - text is best for email. However, in a corporate setting HTML emails consistently outperform text only emails in marketing campaigns, so I can't see them going away any time soon. Is this just a generally accepted view, or has this been studied, with hard evidence and so on? Not that I am suspicious, it's just that people are often told something is true, and they tell others and so on until it becomes a "generally accepted view". I'd be keen to see data to support it. Regards, Peter -- Peter Dominic Ryan | raycity* : new media solutions : proven [EMAIL PROTECTED] | http://raycity.com | mb: 0419 229 738**The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor 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] email stripping out the css from tables?
We do loads of email testing on a wide variety of email clients and web-based email services and I endorse everything in the article that Mathew recommended - it's spot on. In particular the web-based services do some horrible things; in one email we tested, one of them (Hotmail or Yahoo, I can't remember) rewrote the code for a form so it used GET instead of POST, with the result that the form no longer worked. Ordinarily I would offer to test the email for you and help fix it (free of charge) but I am up to my backside in alligators this week - hence I'm working at 1am on Sunday night! I would be happy to do this in the future if anyone has a similar problem. Steve GreenDirectorTest Partners Ltd / First Accessibilitywww.testpartners.co.ukwww.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Bojana LalicSent: 03 July 2006 00:57To: wsg@webstandardsgroup.orgSubject: RE: [WSG] email stripping out the css from tables? No, at the moment my css is embedded in the html, in the part. I am trying to force the table to display the text with the particular styling. Is the following code valid? It probably isn’t, as it doesn’t work, but how do I use inline styles to force the whole table to a certain font style etc. From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Nick LazarSent: Monday, July 03, 2006 9:18 AMTo: wsg@webstandardsgroup.orgSubject: Re: [WSG] email stripping out the css from tables? Do you have an absolute path to the style sheet in the header? i.e http://your-domain.com/css/stylesheet.css" type="text/css" media="screen" /> I think you'll find it will work if you do this. It's also a good idea to include the absolute URL for any images as well Regards, Nick. On 3 Jul 2006, at 09:39, Bojana Lalic wrote: Hi all I am building a newsletter for the email. I used css initially but then the client complained that html wasn’t displaying the content as it should be. Instead of displaying two columns it only displays one and also strips out all the css. I have now started modifying the template and plan to use a table (the client doesn’t care) and a lot of inline styles. So far, I have included a table, however, when the newsletter is sent in an email the table doesn’t seem to preserve the styling any more. It looks perfect in the browser but not in the email. Is email stripping out the css out of tables a known problem? Any tips regarding the use of css and tables in emails would be greatly appreciated. Regards Bojana Lalic Global Summit 2006: Technology Connected Futures -- 17-19 October, Sydney, Australia. Visit our website http://globalsummit.educationau.edu.au for further details. IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. **The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor some hints on posting to the list & getting help** nick lazar 8bits Media http://8bits.com.au ph: 07 5492 4713 mob: 0423 023 613 skype: nick_l email: [EMAIL PROTECTED] **The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor some hints on posting to the list & getting help** **The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor 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] Reccomended Accessible Websites
Take a look at the Accessites website - www.accessites.org. There is a showcase of good-looking, highly accessible sites that all validate to XHTML Strict. Steve GreenDirectorTest Partners Ltd / First Accessibilitywww.testpartners.co.ukwww.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Jason BaylySent: 29 June 2006 07:53To: 'wsg@webstandardsgroup.org'Subject: [WSG] Reccomended Accessible Websites Hi All I’m championing accessible site design here in our office and have a couple of jobs coming up with priority one W3C compliancy as a requirement. Can anyone suggest any sites out there that are best examples of accessible site design? Something professionally designed that caters to all users. I realise the WCAG guidelines are old, and there’s a lot of techniques in use that give even better end results. I haven’t been able to find anything that’s inspirational and looks as good as non compliant sites can do. So any leads on some highly accessible eye candy appreciated. Cheers Jason Jason BaylySenior Developer d: (02) 9274 8061p: (02) 9274 8000f: (02) 9274 8099m: 0425 222 325w: www.newgency.com Newgency Pty LtdWeb | Multimedia | eMarketingAddress:224 Riley Street Surry Hills,NSW 2010Sydney, Australia **The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor 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] IE7 padding, maybe?
Yes, I've been getting them all evening too. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Joe Sent: 28 June 2006 00:07 To: wsg@webstandardsgroup.org Subject: RE: [WSG] IE7 padding, maybe? It seems as though many of the posts from yesterday are being duplicated today. Is anyone else receiving duplicates - or is it just me? Nathan - Thanks for the suggestion. I've also thought about doing it this way, but I was trying to get around doing this without editing the logo. The logo is used on other documents for the company and I didn't want to 'accidentally' mix up the web use one with the actual one. O yah, and I'm not a grate speler. :) Jough -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 3:30 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] IE7 padding, maybe? Hi Jough, What you are trying to achieve is quite tricky. I see some issues with implementing it as you have, because if you start adjusting font size (like I do with my poor eye-sight) then your logo/brand goes out of whack. I would recommend a strategy such as this: Include a and use an image replacement technique to insert your logo to the top right. then use an image editing program to clip the bottom part of your logo where the blue bands go across (which also includes the bottom part of the "r" and "e" in "Pre". Then create the navigation bar and make it the width of the header. Crop the header so that the top part of your logo (above the blue bands). In you navigational menu, make it with a blue background and position the cropped bottom part of the logo as a background (obviously make it line up nicely). Now if the test size grows, so will the blue band and your logo will stay in proportion!! I hope this makes sense? For example -- #header TOP PART OF LOGO -- #navigationBackground bottom cropped part of logo -- Does anyone else see a better solution? Cheers Nathan P.S. Don't take this offensively, I just wanted to let you know that navIgation was spelt wrong in your markup (and resulting CSS) - Original Message - From: "Joe" <[EMAIL PROTECTED]> To: Sent: Tuesday, June 27, 2006 5:40 AM Subject: [WSG] IE7 padding, maybe? > Maybe I'm making this harder than it has to be... > > The webpage in question is located at www.preleads.com/index-dev2.php > > On every computer here in the office (on IE6 and FF1.5) the page displays > fine. But, on one particular computer with IE7 installed the PreLeads > logo > in the top right has about one third of the bottom cut off. I understand > why this is happening (the padding on #header) but do not know if this is > just an IE7 problem if it is even a problem at all. Does anyone else see > the cut-off logo? Does anyone know what is wrong? > > Thanks in advance! > > Jough > > > > ** > 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 > ** > > ** 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 ** ** 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] Screenreaders and AJAX and bears...oh my...
Having just returned from a user-testing session with someone who has severe colour perception impairment (caused by retinitis pigmentosa) I am appalled by this "it's not the designer's problem" attitude. This person uses the ZoomText magnifier, which has a wide range of colour substitution features but on the site we were testing some of the colour combinations were unreadable regardless of which filter was used. It is essential that sites have sufficient colour and brightness contrast to begin with. The difficulty with AJAX and screen readers is how to notify the user when the content has changed, how to tell them which content is now different and how it is different. This is not covered by any standards so it is no surprise that different screen readers behave differently as shown by a couple of recent research articles. I do not believe that this is something the screen reader vendors can resolve by themselves, and it will require input from all sides of the industry to define the required behaviour. However, it is not simply a technical problem because any successful solution will be dependent on the user creating a mental model of the page, modifying it each time the page is updated and keeping track of successive updates. This is no mean feat given that even static websites can be difficult to visualise, and I have no confidence that there will ever be a viable solution that involves asynchronous or 'push' technologies. Steve GreenDirectorTest Partners Ltd / First Accessibilitywww.testpartners.co.ukwww.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of James LaugesenSent: 12 June 2006 23:57To: wsg@webstandardsgroup.orgSubject: Re: [WSG] Screenreaders and AJAX and bears...oh my... I think the only burden placed on developers is to ensure their site can be realisticly processed by a computer.When I consider "accessability", I consider it reffering to accessability by computers... I know that's not how the term is usually used, but that's just how I think about it. Because, in most cases some computer system is acting as an interface between the site/software and the disabled user. The 'old' tables and slicing method left the html virtually useless; the browsers had no idea what they're processing, they can only render it and hope the human viewing the screen can understand it.XHTML is essentially about acheiving that... semantics... and ultimately accessability. I think that's a reasonable responsibility to place on all developers (not just web).However I do think it's unreasonableto expect WEB developers to implement generic solutions to accessability problems, ie, why implement your own screen reader? Or provide facility to change font size? IMO even considering colour blindness is counter-productive, colour correction should be a feature of an 'acccessability-friendly' browser. I'm not much up-to-speed with screen readers; anyone care to educate us? What's hot, what's not, etc?Any WSG members use screen readers? (due to dissability I mean, not just for testing).J On 13/06/06, Gene Falck <[EMAIL PROTECTED]> wrote: Hi Mike,You wrote:>However, what I've noticed that you do not see are articles pushing>the screen reader manufacturers to make more capable and intellegent>readers for the browsers.they seem to be able to do this for >desktop applications (at least to a reasonable level). It seems that>many of the efforts we are making (as well as the WSG) to enable>accessibility are in fact disabling (and in many cases abandoning) the >rich features on the net - this goes back to the whole "magazine>article" site versus the "application" site - two different purposes,>two different needs - both based on the same underlying technologies, >and both need to be accessible.IMO this is because physical access rules came after there werewheelchairs that had, in turn, been developed long after most ofthe physical structures we take for granted were standardized. In spite of that timeline, there were some things that had to bechanged such as the provision of ramps.In web development, we are, then, figuratively, trying to builddoorways and invent the wheelchair at much the same time. Not only is there a major emphasis on web sites doing a lot of thework on this but also our efforts may be obsolete as soon as thenext generation of assisting software is introduced.That may be a discouraging prospect, but I think we still have to keep up as best as we can.--Regards,Gene Falck[EMAIL PROTECTED]**The discussion list for http://webstandardsgroup.org/See http://webstandardsgroup.org/mail/guidelines.cfmfor some hints on posting to the list & getting help The discussion list for http://web
RE: [WSG] UPDATE TO: Using PHP to hide email, script made, testing needed
The W3Schools website states that 10% of users do not have JavaScript but I do not know the methodology behind this measurement nor the demographics of the audience. Some of their stats are wildly different from the other sources we use, and their figure of 25% market share for Firefox is clearly not representative of the market as a whole. I suspect their figures are purely or mostly from visitors to their own site. http://www.thecounter.com/stats/2006/May/javas.php gives a figure of the order of 5% although their figures don't quite add up so there may also be another couple of percent with old versions that cannot be relied on to support all the features built into new sites. I believe these figures are drawn from a much larger and more diverse audience and as such should be more realistic. Earlier this week I was discussing this issue with a web developer at a London hospital and he told me that JavaScript is disabled by means of Group Policies on all of their 1500 PCs. Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Hassan Schroeder Sent: 09 June 2006 16:47 To: wsg@webstandardsgroup.org Subject: Re: [WSG] UPDATE TO: Using PHP to hide email, script made, testing needed [EMAIL PROTECTED] wrote: > I think the most recent stats quote a figure of only 75% or so - 1 in > 4 are not going to be happy! Do you have a citation for that figure? Because I've been working with Web technology since before JavaScript existed, and I've never seen so much as *one* non-technical user with JS disabled. And I realize there are IT departments that disable active content company-wide -- but I've never been in such a company, nor seen any figures on how widespread that practice actually is... -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com opinion: webtuitive.blogspot.com dream. code. ** 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] Is there a way to stop a horizontal text-based Navbar breaking ...?
Alternatively you can put a no-break-space between the words instead of a space. A no-break-space is the six-character string so the link would be something link Contact Us Steve Green Director Test Partners Ltd / First Accessibility www.testpartners.co.uk www.accessibility.co.uk From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Susie Gardner-Brown Sent: 09 June 2006 01:06 To: wsg@webstandardsgroup.org Subject: [WSG] Is there a way to stop a horizontal text-based Navbar breaking ...? I'm setting up a small site that will have horizontal text-based navigation at the top. There's quite a lot of links so it's almost certain to go onto two lines. Some of the links are two words ... Is there a way to stop a two-word link breaking and leaving one word at the end of line 1 and the next at the beginning of line 2? If there isn't, the only other thing I can think of is to make them images ... But maybe someone here has another suggestion? I can't change the number or wording of the links, and they do have to be horizontal. :) ** 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 **
