[WSG] RE: WCAG 2.0 compliance and best practise on the Skip to function [SEC=UNOFFICIAL]
Five 'skip' links is definitely too many and I would say that three is the absolute maximum. During user testing we often get adverse comments if there are more than two. A single 'skip to content' link should be sufficient if the search form and sitemap link are at the top of the page (where people expect them), followed by the navigation then the content. It has been widely accepted in the accessibility community the many years, that accesskeys should not be used because every accesskey conflicts with an accesskey in one or more widely used application or assistive technology. As others have said, not all browsers work correctly with 'skip' links, in particular Safari, Chrome and Opera. It's unbelievable that these bugs have not been fixed after so many years, but that's the case. In my view, most people who benefit from the use of 'skip' links are not likely to be using these browsers. I believe that Opera has the native ability to jump to headings, so that would provide a very similar capability, especially if you add hidden headings for the navigation. I don't believe any other browsers have any such features yet. Steve Green Managing Director Test Partners Ltd From: li...@webstandardsgroup.org [li...@webstandardsgroup.org] on behalf of Blumer, Luke [luke.blu...@ato.gov.au] Sent: 05 June 2012 05:49 To: wsg@webstandardsgroup.org Subject: [WSG] WCAG 2.0 compliance and best practise on the Skip to function [SEC=UNOFFICIAL] Hi All, We are currently in the process of redesigning our website and are looking into the Skip to functionality. We are currently considering using: * Skip to Search * Skip to Primary Navigation * Skip to Secondary Navigation * Skip to Main Content * Skip to Sitemap We are wondering if there is any information on best practice for the Skip to function and whether there is a generally acceptable limit as to how many Skip to links should be used? We are also wondering whether we should be considering other ways for users to navigate around our pages such as AccessKey http://validator.w3.org/accesskeys.html and whether this technique should be used to reduce the number of Skip to links we have listed above? Is there any native browser functionality that performs any of these functions that we should account for? Thankyou in advance for any advice. Regards, Luke Blumer Web Project Officer | Corporate Relations Australian Taxation Office Phone: 02 6216 2970 ** IMPORTANT The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the Privacy Hotline of the Australian Taxation Office, telephone 13 2869 and delete all copies of this transmission together with any attachments. ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] WCAG 2.0 compliance and best practise on the Skip to function [SEC=UNOFFICIAL]
I do not recommend putting the navigation after the content. In fact I would go as far as to say it's a really bad practice because it violates every user's expectation of where the navigation will be. Using CSS to position it above the content makes things even worse because the tab order no longer follows the visual order. The Web Content Accessibility Guidelines specifically state that the DOM order should match the visual order - see http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/C27 I have no problem with the 'Return to top of page' link, although the purists would argue that it is merely replicating the function of the Home key. Of course tablets and mobile phones don't have a Home key, which sort of undermines that argument. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Kevin Rapley Sent: 05 June 2012 22:37 To: wsg@webstandardsgroup.org Subject: Re: [WSG] WCAG 2.0 compliance and best practise on the Skip to function [SEC=UNOFFICIAL] I agree with the consensus that less is more with the skip navigation links at the top of the document. Skip to main content in the majority of cases will be all you need. If you are getting to a point where by rights you need a skip link, to skip the list of skip links, as they have grown so long you know you are following a bad path ;) Another school of thinking is to write the HTML source order so that navigation appears after the content, and use CSS to relocate the menu to the top of the page for sighted users. Of course you would still benefit from a skip link at the start of the navigation menu to skip past it/return to start of content. Note, it is a common misconception that users of assistive technologies linearly read a web page, when in fact the tools they have at their disposal allow them to traverse a page in multiple different ways. For instance, they can call out a dialog which lists all of the links on the page, or gain context by traversing a semantic document tree of the nested headings on the page. In these contexts, skip navigation is largely useless. This may be overkill, I will be interested to hear opinions, but I also place a note with ability to return to the top of the page too: div class=accessibility role=note smallEnd of page./small hr / a href=#pageReturn to top of page/a /div!-- / .accessibility -- /body /html I guess this could be extended to have a further link to Return to start of content. The idea with this is to notify the user that they have reached the end of the document, and rather than leave them at a loose end, give them options to traverse elsewhere. On 5 June 2012 05:49, Blumer, Luke luke.blu...@ato.gov.aumailto:luke.blu...@ato.gov.au wrote: Hi All, We are currently in the process of redesigning our website and are looking into the Skip to functionality. We are currently considering using: * Skip to Search * Skip to Primary Navigation * Skip to Secondary Navigation * Skip to Main Content * Skip to Sitemap We are wondering if there is any information on best practice for the Skip to function and whether there is a generally acceptable limit as to how many Skip to links should be used? We are also wondering whether we should be considering other ways for users to navigate around our pages such as AccessKey http://validator.w3.org/accesskeys.html and whether this technique should be used to reduce the number of Skip to links we have listed above? Is there any native browser functionality that performs any of these functions that we should account for? Thankyou in advance for any advice. Regards, Luke Blumer Web Project Officer | Corporate Relations Australian Taxation Office Phone: 02 6216 2970 ** IMPORTANT The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the Privacy Hotline of the Australian Taxation Office, telephone 13 2869 and delete all copies of this transmission together with any attachments. ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help:
RE: [WSG] Source order of content / navigation
I am familiar with that research but until now I didn't realise that Russ had been involved - well done for the good work. The source order does not only affect people who use assistive technologies. Many people use keyboard-only navigation, and it is very confusing when the visual order does not match the source order. I use a lot of keyboard navigation through choice, not necessity, and the BBC website used to drive me to screaming point because the tab order went all over the place even though the visual order was completely conventional. You never knew where to look to find which element had focus. Thankfully most of the pages using that template have been replaced. We do a lot of user testing with people with disabilities and we find that they use a variety of techniques for navigation. The more-experienced ones will adapt their approach depending on the design of the website. The less-experienced ones do indeed tend to navigate in a linear fashion for fear of missing something important. Don't take any notice of the WCAG guidance from 2005 or earlier. The first draft of WCAG 2.0 was radically different from the version that was finally released. Following widespread criticism there was an almost total rewrite in 2007 and 2008. Your particular reference has been rephrased in the latest version at http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html, and it lacks context such as what the left-hand navigation is for and why it is deemed necessary for the focus to move to the main body content first. As a general principle, meeting users' expectations is important for a good user experience. As Steve Krug said, don't make me think. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Russ Weakley Sent: 05 June 2012 23:53 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Source order of content / navigation An interesting discussion... Back in 2006, Roger Hudson, Lisa Miller and I conducted testing on three aspects associated with screen reader use (skip links, source order and structural lables). The findings regarding source order: t appears that when visiting a web page, most, if not all, screen reader users expect at least the main site navigation to be presented before the content of the page. There appears to be little evidence to support the view that screen reader users would prefer to have the content presented first, or find sites easier to use when this occurs. It is our view, that a continuation of the practice of placing navigation before the content of the page will benefit some screen reader users, in particular those users who are still developing their skills with the technology. It is probably desirable however, to present the content of the page before extraneous information, such as advertisements and related links, as well as the page footer. Interpret as you see fit :) Russ On 06/06/2012, at 8:35 AM, Kevin Rapley wrote: I have started a new thread for this discussion, as not to hijack the thread on skip links. Thanks for the reply Steve. As I said, it is another school of thought (not necessarily my own). I wouldn't use content first source ordering for commercial implementations as the overhead of relocating items in CSS far outweighs any accessibility benefits (at this time). However, with newer layout methods on the horizon, such as CSS flex-box, where reordering source order will be far simpler, this is a very real and worthwhile possibility. I disagree that it is really bad practice. As mentioned, users of assistive technologies will rarely read a page in a linear fashion. WCAG 2 likes to contradict itself (but I am sure you knew that already: WCAG 2.0, includes Success Criterion 2.4.3, which states: 2.4.3 - Blocks of content that are repeated on multiple perceivable units are implemented so that they can be bypassed. (Level 2) WCAG 2.0 - Guideline 2.4.3 The document, Understanding WCAG 2.0 (Working Draft 23 November 2005), includes the following as one of the techniques that can be used to meet Success Criterion 2.4.3: Structuring the content so the main content comes first (in structure - but the default presentation may be a different order), and adding links to the blocks of repeated content. On 5 June 2012 22:57, Steve Green steve.gr...@testpartners.co.uk wrote: I do not recommend putting the navigation after the content. In fact I would go as far as to say it's a really bad practice because it violates every user's expectation of where the navigation will be. Using CSS to position it above the content makes things even worse because the tab order no longer follows the visual order. The Web Content Accessibility Guidelines specifically state that the DOM order should match the visual order - see http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/C27 I
RE: [WSG] WSG - Time for a re-think on WSG.
You wouldn't put up with a web page that forced you to read a short message and hit the delete key before seeing the rest of the page. That's exactly what the new European cookie law is going to force you to do. -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jim Croft Sent: 19 March 2012 03:10 To: wsg@webstandardsgroup.org Subject: Re: [WSG] WSG - Time for a re-think on WSG. yes - it is no big deal as an individual act, but in aggregate contributes to the advere side of the S:N ratio. The fact that it is demonstrably totally unnecessary makes it all the more irritating. Yes, I could write a filter to catch these messages, but this is the 21st century, there are email transfer standards, we have 24 hr wireless pizza delivery, and I shouldn't have to. You wouldn't put up with a web page that forced you to read a short message and hit the delete key before seeing the rest of the page. Chances are you would probably not go there more than twice (the second time to confirm, 'are you for real?!'). If people are already at borderline S:N, 'a very small amount of time' is it all it is going to take to push them over the 'unsubscribe' edge and seek their web standards jollies elsewhere. Also, it is the professionalism thing... jim On Mon, Mar 19, 2012 at 12:35 PM, Jon Reece jon.re...@gmail.com wrote: Personally, I don't mind deleting the few emails (relatively) that are out-of-office replies. If I did, I would probably just set up a filter since I'm using Gmail (and I'm pretty sure most popular email clients support advanced filters as well). I find that the very small amount of time it takes me to select the email, and then select Delete, is really nothing to complain about. Just my $0.02 - Jon On Sun, Mar 18, 2012 at 8:21 PM, Jim Croft jim.cr...@gmail.com wrote: It's not really a web standards issue, but the current acceptable standard for email list servers it to trap 'out of office' messages and /dev/null them with extreme prejudice. If the current list software can not do this, perhap it too should be /dev/null'd. I am subscribed to dozens of email lists and this is the only one that relays out of office spam. Not a good look for a group promoting quality and standards in communication. jim On Mon, Mar 19, 2012 at 9:52 AM, ewen.h...@health.vic.gov.au wrote: rant After a while, we humans decide that small annoyances need to end and after hearing from an individual I don't know that I am off sick today on the WSG group, I have decided enough is enough. What Russ and his band of compatriots did back 15 years or so ago to create a group and spread the word has been fantastic howeever it needs a revival. The vast majority of us are techie, web developers who know a thing or two about great websites that are accessible. Isn't that what WSG is crying out for? Gopher and Archie have sadly gone and so should the current flavour of WSG. WSG could be reincarnated into a thing of beauty and a site to behold beacuse with HTML5, a sprinkling of accessibility knowledge and a bunch of us hacking away, we could show the world that sites can be accessible and uber-cool at the same time. Over to you... /rant PS Hope you're feeling better Ewen Hill Project Manager. ewen.h...@health.vic.gov.au _ This email contains confidential information intended only for the person named above and may be subject to legal privilege. If you are not the intended recipient, any disclosure, copying or use of this information is prohibited. The Department provides no guarantee that this communication is free of virus or that it has not been intercepted or interfered with. If you have received this email in error or have any other concerns regarding its transmission, please notify postmas...@dhs.vic.gov.au ___ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- _ Jim Croft ~ jim.cr...@gmail.com ~ +61-2-62509499 ~ http://about.me/jrc 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.' - Robert Frost, poet (1874-1963) Please send URLs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help:
RE: [WSG] list heading - best practice?
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Oliver Boermans Sent: 07 March 2012 11:20 To: wsg@webstandardsgroup.org Subject: Re: [WSG] list heading - best practice? On 6 March 2012 09:20, Dan Freeman dan.free...@lexi.com wrote: How about in HTML5? section headerSome Title/header ul liItem 1/li liItem 2/li liItem 3/li /ul /section OR: section h?Some Title/h? ul liItem 1/li liItem 2/li liItem 3/li /ul /section How do people feel about a definition list instead for this? dl dtSome title/dt ddItem 1/dd ddItem 2/dd ddItem 3/dd /dl Ollie -- Nooo!!! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] list heading - best practice?
Where do I start? There is nothing right about it. Definition lists are primarily intended for specifying the relationship between a term and its definition. However, the list items following a heading do not define it. Definition lists can also be used for other purposes such as marking up dialog, but none of those purposes apply in this case. An h? heading is all that is required, as others have previously said. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of coder Sent: 07 March 2012 12:42 To: wsg@webstandardsgroup.org Subject: Re: [WSG] list heading - best practice? Come on Steve, tell us why not then? Bob - Original Message - From: Steve Green steve.gr...@testpartners.co.uk To: wsg@webstandardsgroup.org Sent: Wednesday, March 07, 2012 12:31 PM Subject: RE: [WSG] list heading - best practice? -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Oliver Boermans Sent: 07 March 2012 11:20 To: wsg@webstandardsgroup.org Subject: Re: [WSG] list heading - best practice? On 6 March 2012 09:20, Dan Freeman dan.free...@lexi.com wrote: How about in HTML5? section headerSome Title/header ul liItem 1/li liItem 2/li liItem 3/li /ul /section OR: section h?Some Title/h? ul liItem 1/li liItem 2/li liItem 3/li /ul /section How do people feel about a definition list instead for this? dl dtSome title/dt ddItem 1/dd ddItem 2/dd ddItem 3/dd /dl Ollie -- Nooo!!! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Read Speaker?
The merits of ReadSpeaker (and BrowseAloud, which is very similar) have been discussed at great length in the accessibility community for the best part of a decade. There is very little support for them amongst accessibility professionals. My view is that if you have the budget for these services (and they are not cheap) there are much better ways you can spend the money that will benefit more people. Steve Green Managing Director Test Partners Ltd From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of James O'Neill Sent: 21 February 2012 18:34 To: wsg@webstandardsgroup.org Subject: [WSG] Read Speaker? Any thoughts on the Usability or Accessibility of Read Speaker http://www.readspeaker.comhttp://www.readspeaker.com/ If you have any reports, reviews or comparisons that would be great too. Thanks all, Jjim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.orgmailto:memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Read Speaker?
It really depends where you are starting from. If the website is well designed (from an accessibility perspective), you don't need ReadSpeaker at all. If the website is not well designed, ReadSpeaker may or may not be a solution to the accessibility barriers for some people - you just don't know. Bolting on a tool like that does not give you any insight into how accessible or inaccessible the website is, either before or after. Instead I would recommend some form of testing in order to understand what the current accessibility barriers are, followed by a prioritised schedule of remedial work to get to the level you want to achieve. OK, I run a testing company so I am bound to say that, but that would also be the view of most accessibility professionals. Given that ReadSpeaker requires an annual payment that used to be thousands of pounds (what is it now?), that money could fund a continuous program of remedial work that would benefit all user groups rather than the fairly narrow range of user groups that benefit from ReadSpeaker. Steve Green From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of James O'Neill Sent: 21 February 2012 19:58 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Read Speaker? My view is that if you have the budget for these services (and they are not cheap) there are much better ways you can spend the money that will benefit more people. Interesting thought. Examples? Jim On Tue, Feb 21, 2012 at 13:39, Steve Green steve.gr...@testpartners.co.ukmailto:steve.gr...@testpartners.co.uk wrote: The merits of ReadSpeaker (and BrowseAloud, which is very similar) have been discussed at great length in the accessibility community for the best part of a decade. There is very little support for them amongst accessibility professionals. My view is that if you have the budget for these services (and they are not cheap) there are much better ways you can spend the money that will benefit more people. Steve Green Managing Director Test Partners Ltd From: li...@webstandardsgroup.orgmailto:li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.orgmailto:li...@webstandardsgroup.org] On Behalf Of James O'Neill Sent: 21 February 2012 18:34 To: wsg@webstandardsgroup.orgmailto:wsg@webstandardsgroup.org Subject: [WSG] Read Speaker? Any thoughts on the Usability or Accessibility of Read Speaker http://www.readspeaker.comhttp://www.readspeaker.com/ If you have any reports, reviews or comparisons that would be great too. Thanks all, Jjim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.orgmailto:memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.orgmailto:memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.orgmailto:memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessibility: form errors at the end
If you are asking whether there needs to be a link from the error message to the corresponding form control, the answer is no. Steve Green Director Test Partners Ltd From: li...@webstandardsgroup.org on behalf of Sue Sent: Mon 18/07/2011 02:45 To: wsg@webstandardsgroup.org Subject: [WSG] Accessibility: form errors at the end Hi Are there any accessibility compliance issues (WCAG 2, level AA) when a user arrives at the end of a form and validation* from the backend system throws back errors that do not link back to where the error has occurred? *Validation is based on business rules not field errors such as entering invalid email type. Note: current design due to constraints in budget. Thanks in advance, Sue *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** winmail.dat
RE: [WSG] accessibilty: avoid radio buttons?
You are mixing up two unrelated issues. As long as the radio buttons are marked up correctly, they will be WCAG 2.0 compliant. The AFB's opinion is irrelevant in this respect. The AFB's comments are of interest with regard to the user experience, and it would be helpful if they justified their statement. In my opinion, based on years of user testing with screen reader users, radio buttons need not be difficult to use and are almost never very difficult to use. I would agree that they are slightly more difficult to use than a select element, and they are definitely more difficult to use if they are contained in a fieldset and the legend contains a lot of text (the legend is read out before the label for each radio button). You have to balance this against the fact that radio buttons are generally preferred by most users because they can see all the options at a glance and only one click is necessary instead of two. Steve Green Director Test Partners Ltd From: li...@webstandardsgroup.org on behalf of tee Sent: Sun 17/07/2011 00:14 To: wsg@webstandardsgroup.org Subject: [WSG] accessibilty: avoid radio buttons? I am building a site that must meet wcag 2.0 compliant. A web form has radio buttons option, and according to afb.org: Radio buttons are not supported consistently by all versions of browsers, screen readers, and combinations. A correctly labeled and tagged set of radio buttons is a very difficult control for users of screen-reading technology. If a choose only one situation is called for, a select menu is preferable. Is this a sound advice? Thanks! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** winmail.dat
RE: [WSG] Accessibility Testing
We are currently negotiating with one of the major automated accessibility tool vendors to resell their tool in the UK. We cannot sell into the US so I have forwarded your message and they should contact you. In my opinion their tool is better than WatchFire and should also be cheaper. Any tool only tests about 25% of the WCAG checkpoints, whether it's WCAG 1.0 or 2.0, so we would recommend manual testing at various points in the website's lifecycle, such as when developing new templates and perhaps an annual audit. We can provide that service if required. I endorse the other comment regarding the use of Vision Australia's tools if you have the skills to use them. Steve Green Managing Director Test Partners Ltd -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Spellacy, Michael Sent: 24 June 2011 17:16 To: wsg@webstandardsgroup.org Subject: [WSG] Accessibility Testing Hi WSG Friends! The company I work for is considering dropping WatchFire for testing because of the price. I'm really concerned about not being able to test code against specific accessibility guidelines like WCAG 1.0 or 2.0. Do any of you know of any cheaper (or free) applications that do just as good a job? Thanks in advance for any recommendations you may have! Regards, Spell Michael Spellacy Lead User Interface Developer TMP Worldwide Advertising Communications, LLC 125 Broad Street, 10th Floor New York, NY 10004 www.tmp.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Mobile testing methods or emulators
We use two online services - www.perfectomobile.com and www.deviceanywhere.com. These are not emulators - in both cases you are remotely controlling real phones. The theory is great but in practice both services are painful to use for all kinds of reasons including: 1. There is a significant delay between pressing a button and seeing anything change. 2. The display takes a while to update, which makes it difficult to control dynamic content and watch video. 3. Sometimes we could not work out how to interact with the phones. For instance one phone was locked and it took ten minutes to figure out the combination of keypresses (of unlabelled buttons) that was required to unlock it. If you are not already familiar with the phone you are controlling, this is a significant issue. 4. On several phones we were able to open a browser but could not work out how to enter a URL. The smartphones mostly support touch, so you can interact using a mouse, but you can't do that on the more basic phones. The support information is poor on both websites. 5. Security is a concern because we are often working under NDA for major brands on highly secret product releases. Perfecto Mobile simply say that anything you do might be seen by other people, so don't do anything you wouldn't want made public. Device Anywhere claim that each session is private and that they have some sort of cleaning process before the next person uses the phone. However, on one occasion I could see everything that someone else was doing (in real time as they were doing it) and I could not control the phone. Somehow our sessions had got mixed up, which gave me no confidence in their security. 6. Overall it takes much longer to perform any given task - typically 3 to 10 times longer than you could do the task using a desktop browser. Even typing URLs was taking a couple of minutes (they typically contained 50 characters or so), so we had to use a URL shortening service to speed that up. Good luck and let us know if you find a better service. Steve Green Director Test Partners Ltd From: li...@webstandardsgroup.org on behalf of Sean K Sent: Sun 27/03/2011 00:28 To: wsg@webstandardsgroup.org Subject: [WSG] Mobile testing methods or emulators Hi All, I was wondering if anyone could give me an idea how to test sites for mobiles? I'd like to test Blackberry, HTC and IPhone and I was wondering what methods and or tools other people are using for this? Thanks in advance. Sean *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** winmail.dat
RE: [WSG] HTML5 v. HTML 4.x
In my view it depends on who you are and who is paying for the website development. If you are building a website for yourself, by all means spend as much time as you like learning about the new technologies and implementing them. However, if you are building a website for someone else, you should obtain their consent before spending more than is necessary to meet their needs. HTML4 and XHTML1.0 already meet most needs. At first it will take developers longer to build sites using HTML5 because they are less familiar with it, and the client should not have to pay for that if they are deriving no benefit. If you think there may be some unquantifiable benefit in the future, ask the client if they want to pay more now in order to reap that benefit. I am all for the advancement of accessibility but I feel that a lot of developers want to use these new technologies because they are cool and interesting, not because they provide better value for their clients. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of tee Sent: 27 January 2011 00:40 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 v. HTML 4.x On Jan 26, 2011, at 1:34 PM, Steve Green wrote: To the best of my knowledge, all screen readers will 'accept' the new tags insofar as they will read the content between the tags. They just won't do anything with the tags themselves. On 1/25/11 12:34 AM, Steve Green steve.gr...@testpartners.co.uk x-msg://129/steve.gr...@testpartners.co.uk wrote: You can use it, but will anyone benefit from it? Assistive technologies don't support much, if any, of the new semantics. I don't know if search engines and other users of programmatic access to websites are currently able to make use of HTML5 markup, but I have not seen anything to indicate that they do. So what exactly is the benefit? So we don't progress but wait for the screen readers be ready so that we can all merrily hold hands marching forward? I am not sure this type of skepticism does any good to accessibility as a whole-I see it does more harm especially the majority of web community do not think building accessible site a de facto. It probably does more damage coming from well-recognized and respectable accessibility practitioners. How about advice such as if the site needs to be compliant with DDA law, or if the majority users are of assistive devices, think carefully weight over all the pros and crons before jumping on HTML5 wagon? There! I am listening. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] HTML5 v. HTML 4.x
Both those examples are interesting, and underpin my hesitation to move to HTML5. In 2004 one of the largest London design agencies persuaded a corporate client that they could build a complex website using pure CSS layout. We did the compatibility testing (Netscape 6, IE6, Opera 6 etc) and it was disastrous. The site eventually launched months late, over budget and it still looked awful in some major browsers. It was years too early to try anything like that, and they could see that from the alpha test results but they ploughed on. Around the same time, everyone including us started to move to using XHTML. In recent years we all stopped because it was mostly pointless, especially since you cannot serve it with the correct MIME type. These days a lot of us have gone back to HTML4 Strict. Why did we use XHTML? Because it was cool and everyone else was doing so, not because there was any value in it. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of designer Sent: 27 January 2011 13:14 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 v. HTML 4.x I hear what you are saying Steve, but isn't that always the case? The HTML5 scenario is becoming de rigueur now, just as a) tables vs divs and floats and b)XHTML were years ago. It's only by becoming familiar with 'changes' that one can decide for oneself if there are advantages (or not). It's not just 'cool', it's advisable - if you want to make an informed decision. Bob - Original Message - From: Steve Green To: wsg@webstandardsgroup.org Sent: Thursday, January 27, 2011 11:56 AM Subject: RE: [WSG] HTML5 v. HTML 4.x In my view it depends on who you are and who is paying for the website development. If you are building a website for yourself, by all means spend as much time as you like learning about the new technologies and implementing them. However, if you are building a website for someone else, you should obtain their consent before spending more than is necessary to meet their needs. HTML4 and XHTML1.0 already meet most needs. At first it will take developers longer to build sites using HTML5 because they are less familiar with it, and the client should not have to pay for that if they are deriving no benefit. If you think there may be some unquantifiable benefit in the future, ask the client if they want to pay more now in order to reap that benefit. I am all for the advancement of accessibility but I feel that a lot of developers want to use these new technologies because they are cool and interesting, not because they provide better value for their clients. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] HTML5 v. HTML 4.x
That's exactly my point. At any point in time there will be projects where you should use safe, well-understood, well-supported technologies and there will be other projects where you can try out new cutting-edge ones. When making this choice, you should put aside your personal preferences and broader goals (such as 'improving the web' or 'forcing users to upgrade their browsers') and base it on what's most appropriate for your client. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Savl Ekk Sent: 27 January 2011 14:25 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 v. HTML 4.x I think it's all a matter of careful implementation. All such new things must be used in agreement with client. Using graceful degradation, knowing which browsers to support, what technologies available, etc. If we will not use this new technics now, then it wil be hard for browser vendors, web services and device makers to develop them futher. Of course that's all depend on type of site and conditions of work. 2011/1/27 Steve Green steve.gr...@testpartners.co.uk Both those examples are interesting, and underpin my hesitation to move to HTML5. In 2004 one of the largest London design agencies persuaded a corporate client that they could build a complex website using pure CSS layout. We did the compatibility testing (Netscape 6, IE6, Opera 6 etc) and it was disastrous. The site eventually launched months late, over budget and it still looked awful in some major browsers. It was years too early to try anything like that, and they could see that from the alpha test results but they ploughed on. Around the same time, everyone including us started to move to using XHTML. In recent years we all stopped because it was mostly pointless, especially since you cannot serve it with the correct MIME type. These days a lot of us have gone back to HTML4 Strict. Why did we use XHTML? Because it was cool and everyone else was doing so, not because there was any value in it. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of designer Sent: 27 January 2011 13:14 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 v. HTML 4.x I hear what you are saying Steve, but isn't that always the case? The HTML5 scenario is becoming de rigueur now, just as a) tables vs divs and floats and b)XHTML were years ago. It's only by becoming familiar with 'changes' that one can decide for oneself if there are advantages (or not). It's not just 'cool', it's advisable - if you want to make an informed decision. Bob - Original Message - From: Steve Green To: wsg@webstandardsgroup.org Sent: Thursday, January 27, 2011 11:56 AM Subject: RE: [WSG] HTML5 v. HTML 4.x In my view it depends on who you are and who is paying for the website development. If you are building a website for yourself, by all means spend as much time as you like learning about the new technologies and implementing them. However, if you are building a website for someone else, you should obtain their consent before spending more than is necessary to meet their needs. HTML4 and XHTML1.0 already meet most needs. At first it will take developers longer to build sites using HTML5 because they are less familiar with it, and the client should not have to pay for that if they are deriving no benefit. If you think there may be some unquantifiable benefit in the future, ask the client if they want to pay more now in order to reap that benefit. I am all for the advancement of accessibility but I feel that a lot of developers want to use these new technologies because they are cool and interesting, not because they provide better value for their clients. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org
RE: [WSG] HTML5 v. HTML 4.x
To the best of my knowledge, all screen readers will 'accept' the new tags insofar as they will read the content between the tags. They just won't do anything with the tags themselves. From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Ted Drake Sent: 26 January 2011 18:43 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 v. HTML 4.x Hi Steve Can you give some links to research that back up this statement? As far as I know, the screen readers will accept the new tags when you are using something other than Internet Explorer. However, the question is what they do with them. You cannot navigate via articles like you'd use the header navigation. But it's not going to skip an article. The biggest problems with HTML5 accessibility are: repeated h1 headers, longdesc attribute being deprecated, captioning, and placing text within the canvas. At one time there was a conflict when combining ARIA landmarks with the new elements. But this is no longer a problem as the screen reader software was fixed. Ted On 1/25/11 12:34 AM, Steve Green steve.gr...@testpartners.co.uk wrote: You can use it, but will anyone benefit from it? Assistive technologies don't support much, if any, of the new semantics. I don't know if search engines and other users of programmatic access to websites are currently able to make use of HTML5 markup, but I have not seen anything to indicate that they do. So what exactly is the benefit? Steve From: li...@webstandardsgroup.org on behalf of Thierry Koblentz Sent: Tue 25/01/2011 04:29 To: wsg@webstandardsgroup.org Subject: RE: [WSG] HTML5 v. HTML 4.x At the moment, HTML5 doesn't really bring a significant benefit, but that will change (in years rather than months). I beg to differ. I believe there are a lot of great stuff that we can start using today (mostly related to form controls). See http://diveintohtml5.org/forms.html and this one about datalist http://adactio.com/journal/4272/. -- Regards, Thierry @thierrykoblentz www.tjkdesign.com | www.ez-css.org | www.css-101.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] HTML5 v. HTML 4.x
You can use it, but will anyone benefit from it? Assistive technologies don't support much, if any, of the new semantics. I don't know if search engines and other users of programmatic access to websites are currently able to make use of HTML5 markup, but I have not seen anything to indicate that they do. So what exactly is the benefit? Steve From: li...@webstandardsgroup.org on behalf of Thierry Koblentz Sent: Tue 25/01/2011 04:29 To: wsg@webstandardsgroup.org Subject: RE: [WSG] HTML5 v. HTML 4.x At the moment, HTML5 doesn't really bring a significant benefit, but that will change (in years rather than months). I beg to differ. I believe there are a lot of great stuff that we can start using today (mostly related to form controls). See http://diveintohtml5.org/forms.html and this one about datalist http://adactio.com/journal/4272/. -- Regards, Thierry @thierrykoblentz www.tjkdesign.com | www.ez-css.org | www.css-101.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** winmail.dat
RE: [WSG] HTML5 v. HTML 4.x
True, but the vast majority of the websites we work on have a life of less than 12 months, often much less - rebuilding annually or more often is the norm. My inclination is to wait and see what level of AT support develops before putting significant effort into using HTML5. Of course it's different if you're building websites that will be around for years. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of David Dorward Sent: 25 January 2011 09:52 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 v. HTML 4.x On 25 Jan 2011, at 08:34, Steve Green wrote: You can use it, but will anyone benefit from it? Assistive technologies don't support much, if any, of the new semantics. I don't know if search engines and other users of programmatic access to websites are currently able to make use of HTML5 markup, but I have not seen anything to indicate that they do. So what exactly is the benefit? It saves having to rewrite the site when AT, SEs, etc do have significant support for them. -- David Dorward http://dorward.me.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] HTML5 v. HTML 4.x
So called 'semantic classnames' are not semantic at all except in the case of microformats. The whole point of semantic markup is that the author and user agree on the terminology and the meaning, and that is not the case with semantic classnames no matter how obvious they may seem to you. Microformats are the only case I know of where the meanings of classnames have been agreed, published and have some level of take-up. It is possible that smaller groups of people have created their own private schemas. At the moment, HTML5 doesn't really bring a significant benefit, but that will change (in years rather than months). Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of grant_malcolm_bai...@westnet.com.au Sent: 24 January 2011 22:45 To: wsg@webstandardsgroup.org Subject: [WSG] HTML5 v. HTML 4.x Hello, Could someone please clarify this for me. I realise that HTML5 has introduced new semantic elements such as header, aside etc., but does this really increase the expressive power of the markup? Can't the same thing be achieved in HTML 4.x using classes (e.g. p class=header)? I am reluctant to move to HTML5 due to the issue of backwards compatibility. I would be grateful for any replies. Regards, Grant Bailey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessible modal windows / lightboxes
I just tested it in exactly the same operating system and browser, and it works fine. The fact that you are seeing the 'Skip to content' link suggests that the focus is going to the top of the page, not into the lightbox. That happens if JavaScript is turned off, and I can't think of any other explanation unless the JavaScript file is not loading in your browser for some reason. With regard to Birendra's comment, the lightbox has not been made modal, although it could be with a bit more JavaScript. If you tab beyond the end of the lightbox, the focus will go into the page behind it. All you need to do is Shift+Tab to tab backwards into the lightbox. Alternatively, if you press the tab key enough times the focus will eventually return to the lightbox. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of tee Sent: 22 January 2011 10:06 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible modal windows / lightboxes In case you want to investigate further with your developer, my system is OS X 10.6, FF 3.6.13. I don't have status bar enabled by default; with it enabled, I found part of the cause, but the result is still inconsistent. At one attempt, the first tab shows nothing from status bar, and the second tab shows the hidden skip to content got focused. Emptied history, tried again, it showed the same as previously mentioned. tee On Jan 21, 2011, at 8:40 PM, Birendra wrote: Hi Steve Yes it's working fine here but I face one problem, *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessible modal windows / lightboxes
That would do no harm, but I don't think it would be much benefit either. This site is about a year old, and we took the view that ARIA was not sufficiently well supported to be worth using. More importantly, users typically have no idea what it is when they encounter it, so it will be years before ARIA provides any real benefit. Besides, it was difficult enough to get the developers to make the website WCAG-compliant, never mind introducing new concepts they don't understand. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Thierry Koblentz Sent: 22 January 2011 17:48 To: wsg@webstandardsgroup.org Subject: RE: [WSG] Accessible modal windows / lightboxes Hi Steve, Yes, here's one we worked on - http://htmltools.moneymadeclear.org.uk/mortgage-calculator/index.aspx What about using role=alertdialog on that container? http://www.w3.org/TR/wai-aria-practices/#chobet -- Regards, Thierry @thierrykoblentz www.tjkdesign.com | www.ez-css.org | www.css-101.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessible modal windows / lightboxes
Yes, it was tested in all browsers and I just tested it again in Firefox on Windows and Mac - it works ok for me. What is not working for you? I don't understand your point about the placement of the Close button, but I agree that the focus indication should be clearer - we asked for that but it didn't get implemented. Steve From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of tee Sent: 21 January 2011 04:21 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible modal windows / lightboxes On Jan 20, 2011, at 4:44 AM, Steve Green wrote: Yes, here's one we worked on - http://htmltools.moneymadeclear.org.uk/mortgage-calculator/index.aspx Have you tested it on Firefox? It doesn't seem to allow keyboard support for the modal window. Also, a usability glitch IMHO, the close button should be placed in the last keyboard control, reason is that, if the content in the modal window is intended for reading and there are links within it that depends on keyboard control, you won't want users to close the window before they even have a chance to tab through the content. Having the close button placed in the last keyboard control prevents users to close it - once you hit the Get Started (if you miss the enter key (the focus is not as obvious despite the outlined) when you are at the button) it doesn't allow you to go through the tab again to close the window. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessible modal windows / lightboxes
Yes, here's one we worked on - http://htmltools.moneymadeclear.org.uk/mortgage-calculator/index.aspx The problem with most lightboxes is that the position of the focus is not controlled correctly. Typically the user has to tab through all the page content to get to the lightbox content because it has been inserted at the end of the DOM. When they close the lightbox, the focus is not returned to where they originally were on the page. Both of these issues are addressed in the link above, and the result is a seamless experience for anyone using keyboard navigation, including screen reader users. If you give focus to one of the Help buttons and press the Enter key, the lightbox opens and the Close button has focus. If you close the lightbox, the focus returns to the original link. A screen reader will read the contents of the lightbox immediately after the Close button. The only time the focus is not correctly controlled is when the 'Recommend to a friend' or 'Email results' forms are submitted. In these cases the focus returns to the top of the page. The developers tell us it's because they can't control the focus after an HTTP request. Steve Green Director Test Partners Ltd From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of James Grant Sent: 20 January 2011 12:14 To: wsg@webstandardsgroup.org Subject: [WSG] Accessible modal windows / lightboxes Hi WSG'ers, Does anybody have any experience with creating accessible modal windows, aka lightboxes? While I have seen some great lightbox experiments that do allow keyboard control, I haven't been able to find any that will trigger a screen reader to actually read the content within. My project is looking to use lightboxes for field-level help which can contain up to a few paragraphs of textual content, no unique images will appear within the modal window. Once the modal window is open, the only user controls will be to close the window by either selecting the 'close' option, or clicking outside of the content. Thanks! - Jimmy *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] HTML5 - Marking up forms
I'm with Patrick on this one. The form, fieldset and label elements provide all the semantic structure you need. Anything else is noise. Steve Green Test Partners Ltd -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Eric Taylor Sent: 10 November 2010 17:30 To: wsg@webstandardsgroup.org Subject: Re: [WSG] HTML5 - Marking up forms Understandable; however, with the change in HTML5 from Definition Lists to Description lists, would it not be more semantically valuable to mark forms up using dt and dd, for labels and inputs, providing the document with a more solid structure? As stated, my concern with this is the lack of grouping per item, when using Description Lists. I understand that paragraphs may be easier to handle when marking up forms and doing the CSS; however, is it a meaningful method of marking up forms that supports the forward progression of HTML5 and front-end development in general? This is the main reason I'm torn between Description lists and Unordered/Ordered lists. What makes most sense from a semantics view, and where is the balance between semantics and ease-of-use? Eric Taylor Elements Aside / http://www.elementsaside.com On Nov 10, 2010, at 11:41 AM, Patrick H. Lauke re...@splintered.co.uk wrote: On 10/11/2010 17:08, Eric Taylor wrote: From my experience, the best practice, currently, is using Description lists; however, my concern with this method is the lack of semantic grouping when using this set of elements. Another method I have used is using an Unordered list to group each field inside of a list item. However, this doesn't seem like it makes as much sense, semantically, as the Description list. What do you all think, and how do you go about marking up your forms in HTML5? HTML5 does not add any new semantics or constructs to mark up the structure of forms, it only adds new types, a few features (autofocus for instance) and validation functionality. How you actually structure the lot is still as before (and there are still likely heated arguments over which way is good or not...personally, I just use paragraphs, as the extra structure of lists is just overkill in my opinion) P -- Patrick H. Lauke __ re\xAD\xF4dux (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 | http://flickr.com/photos/redux/ __ twitter: @patrick_h_lauke | skype: patrick_h_lauke __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Google 'X-ray' banner
It's just an animated GIF. -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Grant Bailey Sent: 08 November 2010 12:14 To: wsg@webstandardsgroup.org Subject: [WSG] Google 'X-ray' banner Hello, Does anyone know how Google did their 'X-ray' banner that appeared today? (See http://www.telegraph.co.uk/technology/google/8116827/X-rays-150th-annive rsary-celebrated-with-Google-Doodle.html if the banner has been replaced.) It glows and fades. This is not Flash, so I'd love to know how they did it. Does anyone know? Is it an animated Gif, or some HTML5 trick? Thank you, Grant Bailey *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Where are we with Frames?
They are both 'frames' but they are not the same. It's rare that you need to use a frameset, but there's no reason why you shouldn't. Well-designed framesets have performed well in all the user testing we have done, and I would probably go as far as to say they have worked better than JavaScript-based designs. I'm talking about disabled users with assistive technology here, not 'regular' users. iFrames have a fundamental problem that they have fixed dimensions, so increasing the text size results in truncation of the contents. A lot of third-party content providers address this by using fixed font sizes, which just introduces a different problem. Steve Green Managing Director Test Partners Ltd -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of tee Sent: 26 October 2010 03:00 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Where are we with Frames? Are Frameset and iFrame the same thing that often get called as 'frames'? When I think of frameset, I think of this. http://cssremix.com/visit/when-it-drops/ When I think of iFrame, i think of a chunk of javascript that client asks to embed to his/her site, e.g., Google Map, Google Calendar or Payment badge. I don't have issue using iFrame at all, and just checked, HTML5 doesn't make it obsolete. tee On Oct 25, 2010, at 6:37 PM, Stuart Shearing wrote: I agree, traditional frameset layouts should be buried somewhere alongside blink, however I have no issue with iframes and I suspect we're going to see a lot more of them based on articles like this one - http://apiblog.youtube.com/2010/07/new-way-to-embed-youtube-videos.html Stuart *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessibility Testing
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Lesley Lutomski Sent: 22 October 2010 14:49 To: wsg@webstandardsgroup.org Subject: [WSG] Accessibility Testing On 20/10/10 21:13, Nick Stone wrote: Does anyone have suggestions on how to obtain website usability feedback from various members of the disabled community? Kevin Ireson replied with some helpful comments, but I think Nick's main point was that there is no substitute for testing by real people with real disabilities and that can be very hard to achieve. I can try to make my sites accessible to someone using a screen reader, for example, but as I don't use one myself I'm only guessing at how a real user would approach the site. Accessibility testing software is helpful, but doesn't test for all types of disability. For example, there are a wide range of conditions that result in impaired movement, including things as common as arthritis. These can make using mouse and keyboard both quite difficult. With this in mind, might I suggest you visit http://amnestyshop.org.uk/christmas-2010.html and see if you find any potential problems. Would your normal accessibility testing have thrown up these issues, or not? (I apologise for picking on Amnesty; it has the most extreme version I know of a common problem.) I do know of one organisation that arranges site testing by disabled people, but their charges are beyond the budget of any of my clients. Any ideas, anyone? Thank you. Lesley --- Since you ask, we arrange user testing with disabled participants and assistive technologies. It's not cheap but we are more cost-effective than the larger organisations such as RNIB, Shaw Trust and AbilityNet. An intermediate option is an expert review by a consultant with experience of user testing, and we do this when time and/or budget are limited. Obviously it doesn't pick up all the issues that user testing does, but it's a fraction of the cost and it picks up enough issues to be worthwhile. We also provide screen reader training for developers and testers who want an insight into how people use screen readers. This course teaches enough to do some basic testing and provides a lot of guidelines for accessible design (beyond compliance with WCAG). If even this is not affordable, there's no reason why you can't arrange your own user testing. At first it takes a bit of work to find participants, and you will have to pay them an incentive (typically £20 to £30 per hour plus travel). In most cases you can do the testing in people's homes, so you don't need any equipment or software. You will need to read up on how to run user tests to get the best results, but it's not rocket science and there is lots of guidance on the web. There are quite a few disability support groups who will help you find participants, but be aware that those who offer a testing service (such as the three I mentioned above) tend not to be cooperative. Steve Green Managing Director Test Partners Ltd *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Image Maps
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Christian Montoya Sent: 14 October 2010 18:56 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Image Maps On Thu, Oct 14, 2010 at 1:43 PM, Tom Livingston tom...@gmail.com wrote: On Thu, Oct 14, 2010 at 12:52 PM, David Dorward da...@dorward.me.uk wrote: On 14 Oct 2010, at 17:27, Tom Livingston wrote: Are image maps still ok? Still? Server side image maps are as inaccessible as ever. Client side image maps had issues last time I looked at them, but things might have improved since then. http://www.cs.tut.fi/~jkorpela/html/mapalt.html is an (oldish) resource which describes some of the issues and ways to work around them. -- David Dorward http://dorward.me.uk When I say ok I mean as OK as they can be. And the question may have been better as Does anyone still use image maps? Anyway, thanks for the link. Bandcamp is an indie-artist music store service that allows you to design your own storefront, but if you want to link to other sites from your header, you have to use an image map. So yes, there are people out there still using image maps. I'm one of them. But not by choice. -- -- Christian Montoya mappdev.com :: christianmontoya.net We have a client who creates e-learning courses for the public sector, and they make extensive use of image maps. In most cases, clicking the link causes new content to be displayed on the current page rather than loading a new page. We keep telling them to implement the feature differently but they persist despite all the accessibility problems it causes. Steve Green Test Partners Ltd *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] google chrome frame
In our large-ish corporate environment we're stuck with IE6 as our default probably for another year :( While we know that people have installed newer browsersIE7 is authorised, but not the default--we still can't stop supporting IE6. One of the UK high street banks who has tens of thousands of users recently advised me that they will be retaining IE6 as the default browser until 2014 due to the huge amount of work required to fix the large number of bespoke applications they use. Staff can ask for special dispensation to get IE7 installed but if you've ever tried to get a corporate IT department to do anything you'll understand that very few people will bother asking. I think that techies forget the concerns that ordinary people have about technology. Older users in particular are often reluctant to install or change anything because they don't know what they can trust and they are scared something will break. Unlike us, they don't have the knowledge or facilities to fix anything that goes wrong. I suspect that the kind of websites that ordinary people use will still be seeing significant IE6 traffic (probably in excess of 10%) for a couple more years. The stats for techie sites will be very different, so a decision on whether to support IE6 will depend on the demographics of the visitors. FWIW, one of my team was in Bangalore over Christmas and had to use an Internet café. The machines were running Windows 98! So let's not forget that some parts of the world cannot afford to upgrade as fast as we can. Steve Green *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Complex data tables, accessibility and XHTML Basic 1.1
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Kat Sent: 02 November 2009 01:35 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Complex data tables, accessibility and XHTML Basic 1.1 Steve Green wrote: I am tempted to say that this is a moot point. In my experience complex data tables are inaccessible to screen reader users because they have great difficulty forming a mental model of them. Marking them up perfectly semantically doesn't help. If you use 'normal' means of navigating, the table cell contents are read sequentially. Each cell is usually understandable but you get no sense of the structure and relationships with the column and row headings. If you use the table navigation commands, the column and/or row headers are read in addition to the cell contents. This provides structural information but the user has to mentally separate the header and cell data before adding them to their mental model. This is difficult enough with simple tables but I don't recall even highly proficient screen reader users successfully navigating complex tables during user testing. What I can't say is whether any other user group derives any benefit from the correct semantic markup of tables. Off the top of my head I can't think of any. I also cannot think of any applications (e.g. search engines, news scrapers etc) that programmatically access websites that would benefit from this either. Thanks for that Steve! :) Then would the answer, perhaps, be to give a small succinct paragraph about the tabular data, with the most important points (if they exist), and perhaps a link to contact details if the user wanted to know more? And not worry about thead, tfoot, tbody, col, colgroup, etc? Would that be an acceptable accessibility alternative? Kat It depends on what your objectives are. Many of my clients have a contractual obligation to meet the letter of the WCAG, in which case using the correct semantics meets their objectives even though it results in a poor user experience. The same would be the case if you were concerned about the tables being programmatic accessible. If your objective is legal compliance, providing the information by alternative means is certainly an option, and the provision of contact details may well be sufficient depending on the prevailing legal environment. You would need to put in place a procedure to deal with requests for help, and there would likely be a cost - might it just be cheaper to fix the tables? If your objective is a good user experience, don't use complex tables. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] skip links
I always point people to http://blackwidows.co.uk/. The links are accessible to screen readers and are displayed when they have focus so they are accessible to sighted users who use keyboard navigation. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of designer Sent: 28 October 2009 13:37 To: wsg@webstandardsgroup.org Subject: [WSG] skip links Can anyone point me to the best way of providing a 'skip nav' procedure which is invisible to sighted readers but is picked up by screen readers? It seems a can of worms - I've searched and read about it, but (of course) it is impossible to find out which way is recommended by real world web designers who have actually used a bullet-proof approach. I'd be really grateful . . . Thanks, Bob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] skip links
A 1-pixel image works for screen reader users but it is no use for sighted people who use keyboard navigation. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Mark Huppert Sent: 28 October 2009 23:37 To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links spot the typo regards Mark _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Mark Huppert Sent: Thursday, 29 October 2009 10:34 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links Steve One way to do it is make a transparent gif of 1px x 1px. Then embed that in your link with no text. Have an ALT or a TITLE with 'skip navigation' a href=#top img title=Skip navigation alt=Skip navigation src=/screens/dot/gif //a regards Mark Mark Huppert Library Systems and Web Coordinator Division of Information R.G. Menzies Building (#2) The Australian National University ACTON ACT 0200 T: +61 02 6125 2752 F: +61 02 6125 4063 W: http://anulib.anu.edu.au/about/ CRICOS Provider #00120C _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Steve Green Sent: Thursday, 29 October 2009 12:52 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links I always point people to http://blackwidows.co.uk/. The links are accessible to screen readers and are displayed when they have focus so they are accessible to sighted users who use keyboard navigation. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of designer Sent: 28 October 2009 13:37 To: wsg@webstandardsgroup.org Subject: [WSG] skip links Can anyone point me to the best way of providing a 'skip nav' procedure which is invisible to sighted readers but is picked up by screen readers? It seems a can of worms - I've searched and read about it, but (of course) it is impossible to find out which way is recommended by real world web designers who have actually used a bullet-proof approach. I'd be really grateful . . . Thanks, Bob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] skip links
Understood. I was addressing the common misconception that skip links are only for screen reader users. Bob may have had a reason for phrasing the question the way he did, but it probably should have been phrased differently. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Mark Huppert Sent: 29 October 2009 00:19 To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links Thanks for that Steve - but I was trying answer the question: Can anyone point me to the best way of providing a 'skip nav' procedure which is invisible to sighted readers regards Mark _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Steve Green Sent: Thursday, 29 October 2009 11:01 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links A 1-pixel image works for screen reader users but it is no use for sighted people who use keyboard navigation. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Mark Huppert Sent: 28 October 2009 23:37 To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links spot the typo regards Mark _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Mark Huppert Sent: Thursday, 29 October 2009 10:34 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links Steve One way to do it is make a transparent gif of 1px x 1px. Then embed that in your link with no text. Have an ALT or a TITLE with 'skip navigation' a href=#top img title=Skip navigation alt=Skip navigation src=/screens/dot/gif //a regards Mark Mark Huppert Library Systems and Web Coordinator Division of Information R.G. Menzies Building (#2) The Australian National University ACTON ACT 0200 T: +61 02 6125 2752 F: +61 02 6125 4063 W: http://anulib.anu.edu.au/about/ CRICOS Provider #00120C _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Steve Green Sent: Thursday, 29 October 2009 12:52 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] skip links I always point people to http://blackwidows.co.uk/. The links are accessible to screen readers and are displayed when they have focus so they are accessible to sighted users who use keyboard navigation. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of designer Sent: 28 October 2009 13:37 To: wsg@webstandardsgroup.org Subject: [WSG] skip links Can anyone point me to the best way of providing a 'skip nav' procedure which is invisible to sighted readers but is picked up by screen readers? It seems a can of worms - I've searched and read about it, but (of course) it is impossible to find out which way is recommended by real world web designers who have actually used a bullet-proof approach. I'd be really grateful . . . Thanks, Bob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http
RE: [WSG] Accessible Image Map Editors
It may seem strange, but image maps are more accessible to screen reader users than to almost any other user group. They are a significant barrier to some user groups even when correctly coded, so you should provide the information in an alternative, accessible manner. For your class exercise you need to do the following to make the map accessible to screen reader users: 1. Provide an 'alt' attribute for the main image. 2. Provide 'alt' attributes for each of the areas in the map. -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Marvin Hunkin Sent: 25 October 2009 12:36 To: wsg@webstandardsgroup.org Subject: [WSG] Accessible Image Map Editors hi. is image map accessible with jaws? i need to create a image map for a web page i am developing for one of my online programming classes with http://www.johnsmiley.com any recommendations would be appreciated. cheers Marvin. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] dl as paragraph?
Hi everyone. I was just looking at a page on the National Library of Australia web site (http://www.nla.gov.au/services/issnabout.html) and noticed the font rendering was strange in my browser (Firefox 3.5.3). When I looked at the markup to try and understand why, I found that the site seem to be marked up using definition lists for paragraphs. I don't want to jump to conclusions, so can anyone suggest a legitimate reason for doing this? Each paragraph seems to be a new list (not a new list *item*. A whole new list). And the text is in a dd tag with no dt. The strange font rendering (in FF at least) seems to be caused by the font (Myriad Pro) being rendered at %90. Changing either the font size of face appears to fix it. --- Nope - it's so stupid as to barely warrant discussion. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] accessibility: government
It's not that simple. We are working with some UK Government departments that still use WCAG 1.0 and will continue to do so until well into 2010. Other departments have already adopted WCAG 2.0. To answer the question, I do not believe such a list exists, and it would require continuous maintenance as governments switch at varying speeds from WCAG 1.0 to 2.0. This transition may take even longer in cases such as the US who have created their own accessibility requirements based on (but not the same as) the WCAG. Why do you want to know this information? Steve _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Rae Buerckner Sent: 26 August 2009 23:25 To: wsg@webstandardsgroup.org Subject: Re: [WSG] accessibility: government As a general rule of thumb best practice would be to follow W3C guidelines. Cheers, Rae 2009/8/27 Webb, KerryA kerrya.w...@act.gov.au On Thu, Aug 27, 2009 at 4:40 AM, Lucl...@dzinelabs.com wrote: Good afternoon list, Does anybody know if their exists a list of what is required in terms of accessibility features for each country (governments)? -- Regards, Luc Hi Luc, here in Australia we have a couple of pieces of legislation, the main one being the Disability Discrimination Act - there is a guide to it at http://hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm There are some Better Practice Guidelines that touch on a lot of accessibility issues (amongst others) at http://www.finance.gov.au/e-government/better-practice-and- collaboration/better-practice-checklists/index.html Others may wish to add to the list above. To add to Andrew's response, it's not clear if you're asking for general requirements legislated by governments (of all sites) or just for the requirements for government websites. In either case, many countries have multiple levels of government (national, state/province, local) and each level can have its own rules. Kerry (which I work for a state/local govt, and that makes it even more exciting) --- This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. --- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- --- Rae Buerckner E: rae.buerck...@gmail.com M: +61 404 675 028 W: http://www.raebuerckner.com ACT Adobe Products User Group Manager http://groups.adobe.com/groups/8980662cdb/summary *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessible Forms
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Tom Livingston Sent: 19 August 2009 20:10 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible Forms The reason I use this was because I found an easy way to style forms that included the broader compatibility for the clickability of labels for focus with the flexibility of layout with the inclusion of a span like: label for=name spanFirst Name/span input type=text / /label I use this a lot for putting the label text next to the input, instead of stacking, and it gives easy control of this layout. Any info on the wrapping of inputs in a label being bad would be appreciated. We recently tested this exact construction (with the appropriate 'id' attribute in the input element) and got surprising results with JAWS. It does not associate the text label with the form control even though they are associated in two ways (the 'for' and 'id' attributes and the fact that they are enclosed in the label element. JAWS does associate the text label and form control if the span element is not present but that limits your styling options. I have no idea why JAWS behaves this way. Steve Green Director Test Partners Ltd *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] The weirdest IE bug I've ever encountered.
Actually he won't see a bug free site at all. Correcting the doctype and other issues makes no difference. The bug does not occur in Internet Explorer 6. Something like this has been reported previously but the only references I can find are not directly applicable to this situation. http://foorider.blogspot.com/2007/09/css-ie7-float-italic-background.html http://www.positioniseverything.net/explorer/italicbug-ie.html Steve _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Essential eBiz Solutions Sent: 04 June 2009 02:57 To: wsg@webstandardsgroup.org Subject: RE: [WSG] The weirdest IE bug I've ever encountered. Joe is right, you got alot of tags unclosed and you're switch from HTML to XHTML style tags. Pick one, and use the validator! You'll see a pretty much bug free site in no time. _ From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Joseph Taylor Sent: 04 June 2009 02:38 To: wsg@webstandardsgroup.org Subject: Re: [WSG] The weirdest IE bug I've ever encountered. I took a look at your source code - there are a whole bunch of issues beginning with oddities in your HTML - things like: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd; http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd HTML lang=en xml:lang=en xmlns=http://www.w3.org/1999/xhtml; http://www.w3.org/1999/xhtml Your saying the DocType is HTML 4.01 Transitional, but then you're linking to the XHTML namespace - that's probably confusing IE right from the get go. Using Transitional DocTypes also pisses IE off. ul Weird spacees in your tags? That's begging for IE weirdness. Try starting with perfect HTML that's of the Strict DocType whether it's HTML or XHTML. Joseph R. B. Taylor Designer / Developer -- Sites by Joe, LLC Clean, Simple and Elegant Web Design Phone: (609) 335-3076 Web: http://sitesbyjoe.com Email: j...@sitesbyjoe.com On 6/3/09 9:14 PM, Breton Slivka wrote: I have a stripped down example of it here. The bug only occurs in IE 7, and possibly ie6, and it occurs in IE8 running in compatibility mode. I cannot be sure whether it happens in IE8 in IE8 mode or not. (MS have made the compatibility mode interface so bloody complex I can't figure out whether I'm in it or not at any given time). The example is here: http://zenpsycho.com/iebug.htm On that page, you will see an italic letter v on the left hand side of the screen, and a view cart link on the right hand side which is NOT clickable, but which should be clickable. The ingredients of this bug appear to be: * a left floated element followed by * an italic styled element nested directly inside a p tag, which are both preceded by * a menu with links that are floated to the right Combine these things together, and the right hand side of the screen becomes unclickable. (you can have a huge column of links on the right hand side, and they're all useless). What really bothers me about this one, is that the spell is mysteriously broken (the bug goes away) if you change this: Pspanv /span/P to this: Pspanv /spannbsp;/P Just what on earth is going on here? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release Date: 06/03/09 05:53:00 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Image Replacement and Accessabilty
-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]on
Behalf Of Christopher Kennon
Sent: 15 April 2009 01:40
To: wsg@webstandardsgroup.org
Subject: [WSG] Image Replacement and Accessabilty
Hi All,
The text indent CSS property can render an h# element inaccessible to
screen readers. Other than using an img element and alt attribute,
what image replacement techniques are also accessible?
h#{
text-indent: -px;
}
Chris
--
There are lots of image replacement techniques but none of them is
accessible to all user groups. It's a case of selecting the least worst, or
preferably not using image replacement at all.
Typical problems are that the images do not scale if the text size is
changed, you cannot change the colour of the text or background, nothing is
displayed if images are turned off but styles are enabled etc etc.
Techniques such as sIFR or FLIR address some of these issues but none of
them address all the issues, so every technique will be inaccessible to some
people.
Steve
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
RE: [WSG] add to favorites?
It's not just replicating browser functionality - it's a call to action. As such I think it's perfectly reasonable. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Patrick Lauke Sent: 25 March 2009 13:36 To: wsg@webstandardsgroup.org Subject: RE: [WSG] add to favorites? designer Does anyone know of a modern, valid, reasonably cross-browser way to provide a link on a page so that a user can add the page to favourites? The only one I can find is IE only: I know you're probably asking because a client insists on having it, but...have we not evolved yet beyond replicating browser functionality in-page? Will there also be a make this my homepage link? Sorry, being a grumpy bar-stewart today... P Patrick H. Lauke Web Editor Enterprise Development University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 webmas...@salford.ac.uk www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] add to favorites?
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Andrew Maben Sent: 25 March 2009 15:18 To: wsg@webstandardsgroup.org Subject: Re: [WSG] add to favorites? On Mar 25, 2009, at 10:10 AM, Steve Green wrote: It's not just replicating browser functionality - it's a call to action. But the action you're calling for is indeed a replication of browser functionality. Calling something by another name does not change what it is. So previously stated arguments against doing it still stand. Andrew Maben www.andrewmaben.net and...@andrewmaben.com -- It makes no sense to me that you would provide a call to action and then not provide a means for the user to perform that action when it is so easy to do so. That will inevitably result in fewer people performing the action than would have done if you provided the means to do so. That's fine if it's your site but you are doing your clients a disservice if you do it to theirs. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] add to favorites?
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Stuart Foulstone Sent: 25 March 2009 16:19 To: wsg@webstandardsgroup.org Subject: RE: [WSG] add to favorites? This list is aware of many marketing practices that are against Web Standards. -- Is this list interested in discussing how to balance the conflicting requirements of various stakeholders (including marketers) or does it take the dogmatic position that compliance with web stardards trumps everything else? Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] a WCAG 2.0 question
It's not just screen readers that have problems with new windows. Every user group we have tested with has had problems. Screen reader users sometimes do not notice that the screen reader has announced the opening of a new window. Screen magnifier users frequently cannot tell that a new window has opened, particularly if it is larger than their screen, which is invariably the case at anything over 4x magnification. Even sighted users often do not notice. This is especially the case if a link opens in a new tab rather than a new window. The best practice is not to open new windows at all, regardless of what WCAG 2.0 may or may not say. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jon Gunderson Sent: 12 March 2009 14:23 To: wsg@webstandardsgroup.org Subject: Re: [WSG] a WCAG 2.0 question I think this requirement is a little out dated, screen readers today do a good job of telling people that a new window is open. I think the main concern is window pollution, if links are opening a lot of new windows it can be difficult for people with some types of disabilities to be aware of and find windows they are interested in. I believe a best practice is for your web pages to use the same TARGET attribute value so links from your page basically are updating the same new window and not creating a new window for every link followed from your website. Jon On Thu, Mar 12, 2009 at 1:58 AM, Glen Wallis glen.wal...@velocitynet.com.au wrote: Hello all I am interested to know whether the people on this list consider opening a new window without alerting the user to be a failure to conform to Success Criterion 3.2.2 of WCAG 2.0. The success criterion is as follows: 3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. (Level A) The key phrases, I believe are user interface component and change of context. I looked up the definitions of both phrases. The glossary states quite clearly that a link is a user interface component and that a change of context includes opening a new window. However, the document Understanding SC 3.2.2 says Additional Techniques (Advisory) for 3.2.2 Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations. Giving users advanced warning when opening a new window. (future link) This seems like a contradiction. The WCAG 2.0 Recommendation is the only normative document, so it should take precedence over the Understanding document. However, the Understanding document specifically states that warning the user is not required for conformance. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] embedding quicktime .mov cross-platform
I don't allow QuickTime to be installed on any of our machines either. Is there a reason why you can't use a file format that has a larger installed user base? Most non-Mac users won't have QuickTime. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Nancy Johnson Sent: 15 January 2009 18:58 To: wsg@webstandardsgroup.org Subject: Re: [WSG] embedding quicktime .mov cross-platform Firefox 2 asked for quicktime plugins. My company won't allow you to install quicktime on their pcs. Nancy On Wed, Jan 14, 2009 at 3:10 PM, Ron Zisman ronzis...@mac.com wrote: anybody know of a solid way to embed quicktime movies cross-platform--in a standards sort of way. i've googled around and haven't found what i need. i'm told my current method hates IE. surprise. test page here: http://www.ricochet.org/test_flippin/georg_tampered.html thanks in advance --ron *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] credibility of accessibility validator and evaluator
Accessibility validators should make it very clear where a checkpoint is required by a standard (in which case they should provide a reference so you can check the precise wording) and where it is 'best practice' (according to who?). In this case the 'failure' is not a non-compliance with any standard, and I would not even describe it as a 'best practice'. To be a 'best practice' there should be a consensus amongst professionals in the field that the practice is applicable in all cases where it is relevant. I have never seen this practice mentioned or discussed previously, and I am sure there will be cases where it is not necessary or desirable. Use the accessibility validators insofar as they are useful to you, but don't be a slave to them. If you learn the rationale behind all the checkpoints you will understand how to balance conflicting requirements and know when it is safe to ignore them completely. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of tee Sent: 31 December 2008 10:43 To: wsg@webstandardsgroup.org Subject: [WSG] credibility of accessibility validator and evaluator I was testing the FAE the first time, and is questioning its report credibility because it fails my document title 50%. Not that I don't like to be wrong :) According to the report: Document Title Best Practices * The page should contain exactly one title element. * Pass: 1 title element was found. * The text content of each h1 element should match all or part of the title content. * Fail: 0% (0 out of 1) I cannot find any information about h1 content should match part or all of the title content on WCAG 2.0 guideline. There isn't guideline reference link to WCAG 2.0 official site, and I couldn't find such info on WCAG official document. Though from the SEO point of view, this 'advice' makes sense. This also makes me wonder how reliable those accessibility validators are because I get different results from Cynthia Says and Total Validators-these are the two I frequently use. Note: I am fully aware an accessible site can't just rely on validator but extra human eyes and care. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] jquery ui.slider keyboard navigation question
It is understood that some tasks will require two keys, such as Alt + down arrow to open a combobox. I presume you are testing on a Mac because I see slightly different behaviour than you describe in Windows browsers. In both Internet Explorer 6 and Firefox 2.0 the arrow keys alone are sufficient to operate the sliders. However, if the window has a scrollbar, both the slider and the scrollbar move at the same time in both browsers. If the Ctrl key is used in addition to the arrow key, only the slider moves. Steve -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of tee Sent: 12 December 2008 16:46 To: wsg@webstandardsgroup.org Subject: [WSG] jquery ui.slider keyboard navigation question It's more an accessibility question so I thought I am posting my question here. jQuery site claims that the ui.slider has keyboard navigation support. I tested in FF, Safari and Opera, the result varies. In FF and Opera, I needed to hold down Control Key with left/right arrow In Safari, left/right arrow works fine. http://dev.jquery.com/view/tags/ui/1.5b2/demos/ui.slider.html Two questions: 1) When we say keyboard navigation for website, is it common to expect only one keystroke for one task? 2) and that it applies to browsers that support tabbing navigation consistently? I can't figure from the code whether the different behaviors in above browsers are caused by the script or a browser default behavior. Thank you! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] jQuery problems
I would be grateful if any JavaScript (specifically jQuery) experts could contact me off-list as I have a client who needs some remedial work done (for which they will pay). Also are there any more suitable places I could post this request? Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] the Name attribute
Stuart's point is that blinking content violates checkpoint 7.2 of the W3C
Web Content Accessibility Guidelines:
Until user agents allow users to control blinking, avoid causing content to
blink (i.e., change presentation at a regular rate, such as turning on and
off)
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Hall
Sent: 28 November 2008 20:44
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] the Name attribute
On Fri, 2008-11-28 at 13:07 +, Stuart Foulstone wrote:
Blinking text is against standards in itself, so how can you do it in
a standards compliant way?
Using the sample I posted - see below. That validates.
Cheers
Dave
On Fri, November 28, 2008 10:45 am, Dave Hall wrote:
!-- ... --
head
style type=text/css
/* ... */
.blink{
text-decoration: blink;
}
/* ... */
/style
!-- ... --
/head
body
!-- ... --
span class=blinkmy blinking test/span
!-- ... --
/body
instead of
!-- ... --
blinkmy blinking test/blink
!-- ... --
***
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] Text-only version
Betsie does a lot more than just display the page without styles. It was
designed to improve the accessibility of the crappy websites that were the
norm a decade ago, and it is less useful on a website that is coded properly
but it still has some value. The technical spec is at
http://www.bbc.co.uk/education/betsie/tech.html
You can do a lot of what Betsie does using CSS but the one thing you can't
do is replace the images with their 'alt' attributes.
Steve
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tom ('Mas) Pickering
Sent: 20 November 2008 20:20
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Text-only version
Rob -
What I would interpret that to mean is that, by clicking on the link in the
footer, the visitor will be presented the content either without any
graphics or without any graphics or CSS. If it were merely a matter of the
CSS being removed, that shouldn't be a billable item. However, if all
graphics are removed from the page, then you would have a different version
of the page and that would be billable, though it would likely involve less
time to modify the original template to have a text-only version.
In either case, I would seek detailed clarification of that line item from
their estimate.
At 01:53 PM 11/20/2008, you wrote:
Dear list,
I'm involved in a CMS-based website project where the supplier has
provided me with a breakdown of costs - before I sign it off.
One of the items highlighted in the breakdown is a footer-accessed
link for a text-only version. The supplier claims it's the same
technology used/developed by the BBC - called Betsie.
Do you think it's a service I should be paying for? Although not
expensive, I'm wondering why the 'functionality' needs to be
highlighted at all? Surely, it's the same as saying we'll charge you
separately for css or html markup?
Thoughts...
Thanks,
-- Rob
// Rob Enslin
// twitter.com/robenslin
// +44 (0)759 052 8890
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Tom ('Mas) Pickering - Web Developer Patti Gray - Web Designer
[EMAIL PROTECTED] [EMAIL PROTECTED]
PourHouse Productions - http://pourhouse.com/
When He Reigns - It Pours )
***
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] Text-only version
Agreed. If you've got a user agent that does what you need, Betsie doesn't really add anything. If you don't have access to your own machine (and none of us do all of the time) then it does perform a useful function for some people. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 20 November 2008 20:54 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Text-only version Steve Green wrote: You can do a lot of what Betsie does using CSS but the one thing you can't do is replace the images with their 'alt' attributes. Unless you set your user agent to do that, because presumably that's something you'd need on all sites, not just one particular one. 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 __ Co-lead, 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] Text-only version
Yes it does. It allows the creation of a text-only version for people who need one but don't have a suitable user agent on the machine that they currently have access to. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Montoya Sent: 20 November 2008 21:07 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Text-only version On Thu, Nov 20, 2008 at 3:40 PM, Steve Green [EMAIL PROTECTED] wrote: You can do a lot of what Betsie does using CSS but the one thing you can't do is replace the images with their 'alt' attributes. Does this solve some problem? -- -- Christian Montoya christianmontoya.net *** 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] Text-only version
Yes, of course you can do stuff like this, although it gets pretty ugly and
bloated if you have a lot of images. The point of Betsie is that it can be
retrofitted to existing websites without the need to modify any code.
It also caters for people who are working on a machine that is not
configured to their needs and cannot be altered e.g. in an Internet cafe or
a locked-down machine in someone else's office. Your image replacement
technique does not cater for these situations unless you also add a style
switcher, but that appears to be taboo in this list.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Dorward
Sent: 20 November 2008 21:06
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Text-only version
Steve Green wrote:
You can do a lot of what Betsie does using CSS but the one thing you
can't do is replace the images with their 'alt' attributes.
CSS is quite capable of that.
The following works fine in Opera 9.62 (the only browser I've bothered to
test for this proof of concept).
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
titleReplace Image With Alt/title
style type=text/css
img {
height: 0; width: 0;
}
img::after {
content : attr(alt);
}
/style
h1Replace Image With Alt/h1
div
img src=http://dorward.me.uk/images/wheel/logo.png;
alt=Dorward Online
/div
--
David Dorward http://dorward.me.uk/
***
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] Text-only version
I see where you're coming from, but the logical extension of your argument is that there are never any instances where it is necessary to use images to convey information. That is certainly often the case, but can we say 'never'? You are not always able to make sites as semantically pure as you might wish (unless you are prepared to walk away from a lot of work). For instance I am currently working with a group of large retail brands where the brand managers will absolutely not permit the degradation of the visual appearance by replacing the graphical representations of text with real text. We're not starting with a clean sheet, so a jump to a pure semantic website just isn't going to happen in one step (at least not in the timescale they are looking for). Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Montoya Sent: 20 November 2008 21:33 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Text-only version On Thu, Nov 20, 2008 at 3:40 PM, Steve Green [EMAIL PROTECTED] wrote: You can do a lot of what Betsie does using CSS but the one thing you can't do is replace the images with their 'alt' attributes. Does this solve some problem? On Thu, Nov 20, 2008 at 4:19 PM, Steve Green [EMAIL PROTECTED] wrote: Yes it does. It allows the creation of a text-only version for people who need one but don't have a suitable user agent on the machine that they currently have access to. I'm still not seeing the problem for the solution. If you can't see images, does the alt text really help? I don't mean to sound annoying, I'm just trying to see the point of using Betsie on a semantic website. -- -- Christian Montoya christianmontoya.net *** 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] Big Browsing Issues on clients PC Laptop AOL
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Pennell Sent: 18 October 2008 20:22 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Big Browsing Issues on clients PC Laptop AOL On Sat, Oct 18, 2008 at 7:19 PM, Kristine Cummins [EMAIL PROTECTED] wrote: I just launched a site, and it's browsing fine on my PC Mac laptop from IE5-8 browsers to FF etc. However, when my client visits her site on her PC laptop using AOL, it is browsing (as if) the stylesheet is applying only half way. I've recommended her to download the latest IE or FF, but she hasn't done it yet. When she goes to her place of work, it looks fine. How could there be this huge discrepancy on her PC Laptop using AOL? I can't speak for recently, but years ago AOL used to basically install itself *as* your browser. The browser would be badged AOL, and it wouldn't render quite like anything else that was around at the time. Now this was probably around the time of IE4, so I would hope that things have changed - I just checked the analytics account for a huge (180m pageviews/month) site, and there are zero records of any browser with the string AOL in the identification string, which suggests that there is currently no such thing as an AOL browser. Perhaps your stylesheet is cached by an AOL proxy? - Matthew -- Since AOL5 (and possibly earlier) the Windows version of AOL has used the Internet Explorer rendering engine. If a suitable version of IE was already installed it used that, otherwise it installed a newer version. It would be interesting to see if the same problems occur when she accesses the website using Internet Explorer. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Fieldsets Legends
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 03 October 2008 10:03 To: wsg@webstandardsgroup.org Subject: [WSG] Fieldsets Legends Hi, I'm trying to educate developers to add fieldsets and legends to their code when building applications. Jaws 5.0 handles fieldsets and legends in the form field dialog box but jaws 9.0 doesn't. I've spoken to freedom scientific and they say this Therefore, there is really no setting in JAWS 9.0 that can be changed to cause the List of Form Fields dialog to behave in the same manner as it in JAWS 5.0. Does anyone have any thoughts on this matter or know of any software that does support fieldsets and legends! Thanks Clare -- Can you explain what problem you are trying to solve? You can't change what user agents people have, so what is your objective? Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] WCAG2 in general
Further to the discussion regarding WCAG 2.0 in government, I am interested in the reasons why organisations are or are not choosing to adopt WCAG 2.0. Would anyone care to share their thoughts? Are you adopting it just because it's new and presumably better? Or have you reviewed it thoroughly and concluded that it really is better? We are still in the process of taking a position on this, but at the moment we are profoundly negative about WCAG 2.0. I can see few ways if any that it will directly benefit website users, and the whole focus appears to be on making life easier for developers by taking out the difficult stuff or pretending it's not a problem. The only benefit I see is that some developers may embrace accessible design if it is easier to meet the guidelines, which may lead to a general (but limited) improvement in accessibility. However, this will be offset by a lowering of standards at the top end unless developers go beyond what WCAG 2.0 requires (and what's the chance of that?). Does anyone think that WCAG 2.0 will improve the user experience? Or do you take my view that it only benefits developers, and that the user experience will be worse in future? Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Google chrome... Accessibility coming very soon???
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Martin Sent: 04 September 2008 23:33 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Google chrome... Accessibility coming very soon??? Hey guys... it is great that talk about accessibility and chrome has been raised - but I do think that we need to wait until it is out of beta. Cheers Adam -- Why? Accessibility can't just be bolted on afterwards - it needs to be designed in from the start. The fact that the application cannot be used with just a keyboard is criminally negligent - that's a fundamental requirement of any application. The simplicity of the UI means it should have been really easy, and the fact that the application is device-dependent suggests that accessibility isn't on their radar at all. The fact that keyboard-only users, screen reader users and others cannot use the browser at all means that they are entirely excluded from the beta phase, so it seems they will not be able to provide feedback until it goes gold, if it ever does. For an organisation with Google's resources this is totally unacceptable. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Google chrome... Accessibility coming very soon???
Yes, this is the case. There has been a lot of talk about this in GAWDS, and Steve Faulkner has written about it at http://www.paciellogroup.com/blog/?p=92. Basically it looks like there's no MSAA support. If they don't address this, many large organisations (at least in the UK) will not use it. I imagine that such organisations are exactly the people Google are expecting to build applications using Chrome, so hopefully this will be addressed at some point, ideally before it comes out of beta. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kevin erickson Sent: 03 September 2008 16:07 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Google chrome... Accessibility coming very soon??? I have a huge concern about accessibility here. Apparently Jaws and other screen readers don't work on Google Chrome at all. Can others please confirm? kevin *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Shopping cart - who does what
Thanks Steve for the clarification. OK, in the risk of showing more ignorant, I still have question. My understanding on WCAG guidelines, are the fundamental principle of DDA, Section 508 and similar law in other countries correct? When a website is to be DDA or Section 508 compliant, for lack of better guideline (or none) from the DDA law, we follow WCAG guidelines because there aren't anything else we can base on. Is it not that UK websites are to to be WCAG AA compliant so that it meets UK DDA compliant? 'Reasonable measures' takes into account that is correct; personally I feel that making an accessible site for all people regardless of disability take one's common sense, sensibility and compassion towards others who are at disadvantage doing certain things that most people like us take it for granted, these are also reasonable measures I think. Since the DDA law has not drafted out a comprehensive guideline for website maker/owner to follow but an unofficial WCAG we depend on, I think 'reasonable measures' can also be favored by defendant with his [EMAIL PROTECTED] lawyer :-) Under British law, can individual who brings a case under the DDA and the lawyer seek monetary compensation? Couple months ago a handful of ADA lawsuits handled by a same lawyer. http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2008/06/13/carollloyd.DTLh w=disability+lawsuitsn=001sc=1000 I followed the story because one of my clients was affected, she closed her business as a result. After reading some background stories, I am not sympathize to the plaintiffs. If a lawyer filed over 1500 cases like this, and fatten his wallet on every case, it's hard to convince that he was fighting for a just and noble cause but a tumour for ADA/DDA. If lawyer and plaintiff can seek monetary compensation, I honestly hope no ADA/DDA law ever applies to website. tee -- The DDA is only relevant if both the user and the website owner are based in the UK. In all other circumstances it can and should be ignored. And it has absolutely nothing to do with the WCAG. The DDA does not require WCAG compliance and does not even mention it. WCAG compliance could be used as part of a defence that reasonable measures were taken, but it may not be sufficient (the court may believe that the website owner had sufficient resources to conduct user testing that would have revealed accessibility issues that the WCAG testing missed). Section 508 only applied in the US, and only to Federal or Federally-funded websites. In all other circumstances it can and should be ignored. All of which leaves us with the WCAG, which are universally recognised. Unless a country has its own set of guidelines, WCAG is all you need to be concerned with. An individual who brings a case under the DDA can seek monetary compensation. However, the law is supposed to be a last resort, and users are expected to give the website owner the opportunity to make the website accessible before resorting to law. Failure to do so suggests that the plaintiff is just looking for a payout and that they are not actually interested in being able to use the website. The situation may be different in the US but you're not going to get ambulance-chasing lawyers stirring up trouble in the UK. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Shopping cart - who does what
On Aug 14, 2008, at 3:09 AM, Krystian - Sunlust wrote: It costs £300 man, I would prefer to get an open source solution, community paid support. Try getting support from Magento, likely £300 is comparably very inexpensive, considering that commercial software ought to give you support on every question you asked (if not, you go spread the bad word) :-) excerpt from tradingeye: Accessibility WCAG AAA UK DDA aware Section 508 aware Placing 'WCAG AAA', DDA, Section 508 aware, it makes think they don't really know what they are taking. If they have scored AAA (how many sites you built have achieved this ?), why add the other two? tee I have no idea what they mean by UK DDA aware. DDA is not a technical standard and has nothing to do with the WCAG. Compliance with WCAG (even AAA) is no guarantee that a site meets the requirements of the DDA. The latter is concerned with 'actual outcomes' i.e. can people with disabilities access the site. It is reasonable to include Section 508 because it is not a subset of WCAG AAA. It is substantially based on WCAG but it has additional requirements. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Shopping cart - who does what
I thought that UK DDA is based on the WCAG AA guideline no? One time I did a template coding for a UK company, and was asked to follow WCAG AA guideline. As for Section 508, my impression is that, despite the additional requirements, it doesn't even quite meet the WCAG A. In the early years of my Standard Compliant pilgrim, I did a couple sites that were WCAG AAA compliant (if Bobby was right) so that I could get a field experience then reading the WCAG guidelines that I have had difficulty to comprehend. I agree that compliance with WCAG is of no guarantee that a site is fully accessibly, however, I do think that if a site scores WCAG AAA, it pretty much covers section 508, and maybe UK DDA (I am not very famliar with this guideline). tee No, the DDA is not based on WCAG. The DDA is not a technical standard, it is a UK law. If a website is not accessible to someone, they can (in theory) bring a case against the website owner under the DDA regardless of whether the website meets WCAG A, AA, AAA or any other technical standard. If the court deem that the website owner did not take 'reasonable measures' to ensure that the website is accessible, they will lose the case. 'Reasonable measures' takes into account all relevant factors including the resources available. In the case of a small company with a website with complex content such as a GIS (geographic information system) the court may well deem that it would not be reasonable to expect the company to bear the cost of making it accessible (to the particular person who brought the case). The site would therefore be DDA compliant (for that person) despite not even meeting WCAG A. Note that only an individual can bring a case under the DDA because it is necessary to show that they have suffered discrimination. It is not possible to bring a class action, nor can a third party (such as a lobbying group) bring an action although they may support an individual in bringing the action. The findings of the court only apply to that individual so the phrase 'DDA compliant' actually has no meaning except in its application to a single person. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Reverting to older version of flash for testing purposes.
You can get an uninstaller from the Adobe website - http://www.adobe.com/support/flashplayer/downloads.html#uninstaller You can get every old Flash version at http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266 http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266sliceId= 2 sliceId=2 Ensure all browsers are closed before uninstalling, and reboot afterwards even if you are not prompted to. We do this many times every day, and the uninstallers do screw up occasionally, particularly on Windows. Sometimes it leaves you such that Flash does not work but you cannot install a new version. At that point we just restore a new disk image. Note that on the Mac the uninstaller will uninstall every instance of Flash from every browser on every partition it can get to (if you have multiple OS X versions on a partitioned hard disk as we do). Likewise the installer installs the same Flash version onto every browser on every partition so you can't have different Flash versions on the same machine. There may be a way to hack this but I can't figure it out. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Caleb Wong Sent: 09 July 2008 00:05 To: wsg@webstandardsgroup.org Subject: [WSG] Reverting to older version of flash for testing purposes. Hi, Does anyone know of if there are ways of reverting to a older version of flash (i.e 7) for testing purposes on a MAC or PC? Cheers, Caleb *** 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] ADA Compliant Flash
If ADA requires compliance with Section 508 (and I am not sure if it does), then you would need to provide the content in an alternative, accessible format regardless of how accessible the Flash version is. My reasoning is thus: Checkpoint m) of Section 508 states When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l). Clearly it is not possible to provide such a link for user agents that do not support Flash, so in my opinion this checkpoint cannot be met for any Flash-based content. Checkpoint k) states A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. This would appear to allow you to achieve compliance, albeit in a rather sub-optimal manner. On a separate issue, can I take the opportunity to advertise a permanent job vacancy for a website tester / accessibility tester / consultant. This is a mid-level to senior position based on London and I am offering a substantial finders fee for anyone who can introduce a candidate that we recruit. Full details are available on request. Steve Green Labscape www.labscape.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Livingston Sent: 07 July 2008 15:37 To: wsg@webstandardsgroup.org Subject: [WSG] ADA Compliant Flash Hello list, Is it possible to have an ADA (no, not the dentists' thing) compliant Flash site? Anyone have a good resource, if it is possible? All my searching has resulted in the feeling that this subject is one people avoid. -- Tom Livingston | Senior Interactive Developer | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.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] ADA Compliant Flash
Thanks for the clarification Dennis. If it turns out that ADA does cover websites, what would be the test for compliance? Or is it likely to be similar to the DDA in the UK, which is concerned with actual outcomes rather than a technical standard? Under the DDA it doesn't matter if a website is AAA-compliant (if such a thing were possible); a person can still bring an action if the website was not accessible to them (although there is no guarantee they will win). Only a court can decide if the website met the law or not. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Lapcewich Sent: 07 July 2008 21:50 To: wsg@webstandardsgroup.org Subject: RE: [WSG] ADA Compliant Flash Clarification. Section 508 and ADA are about as different as fishes and bicycles in intent, direction, scope and application. Section 508 is part of Rehabilitation Act of 1973, as amended. It only applies to US Government web sites and those sites built/maintained with (US) federal tax dollars. ADA is shorthand for the Americans with Disabilities Act of 1990, as amended. The prevailing point of view (until recently) is ADA has nothing to do with the web. However the Target.com court case and other (US) state thoughts are that ADA applies to all web sites within its jurisdiction. Time will tell on this point. Dennis Lapcewich USDA Forest Service Webmaster DRM Civil Rights POC R6 Web Accessibility Monitoring Program Pacific Northwest Region - Vancouver, WA 360-891-5024 - Voice | 360-891-5045 - Fax [EMAIL PROTECTED] People who say it cannot be done should not interrupt those who are doing it. -- Anonymous [EMAIL PROTECTED] wrote on 07/07/2008 09:10:49 AM: If ADA requires compliance with Section 508 (and I am not sure if it does), then you would need to provide the content in an alternative, accessible format regardless of how accessible the Flash version is. My reasoning is thus: *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Browsers and Zooming
I have never encountered a friend, family member or other civilian who has a problem scrolling in either direction if necessary. A horizontal scrollbar does not prevent users from accessing content but it reduces the efficiency with which they can do so. Not only does zooming introduce the horizontal scrollbar but it greatly increases the amount of vertical scrolling that is required compared with text sizing. Horizontal scrollbars cause terrible usability problems for people who use screen magnification because the scrollbar is not present except when they scroll to the very bottom of the page. If the content they wanted to view was in the top right-hand corner they have to scroll to the bottom of the page and back up again. Having seen this occur during many user testing sessions I advise strongly against horizontal scrollbars. In my view, zooming and text sizing are appropriate for different needs. For relatively small text size increases I think that text sizing is appropriate because it does not result in a horizontal scrollbar. If larger text sizes are required I would advise people to use the zoom function because the page layout often breaks badly at large text sizes (there are limits to what is achievable even when a site is designed well). Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Sparber Sent: 03 July 2008 20:41 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Browsers and Zooming I wonder what a partially sighted user would thing of these 'improvements'. Would they be glad that now they can see images a little easier and the layout seems to break less or would they be annoyed at the sudden appearance of a horizontal scrollbar? I think web developers have an irrational fear of scrollbars :-) They are tools to scroll a window, not signs of bad design. I have never encountered a friend, family member or other civilian who has a problem scrolling in either direction if necessary. For folks who need to increase the text size for a specific page (perhaps because the designer set microscopic font-sizes) a true zoom, rather than a text resize, preserves the line-length proportions in a fixed-width layout. Or would they be using screen magnification software anyway, and it wouldn't make a difference to them? Probably not. There are far more important issues to get bogged down in ;-) -- Al Sparber - PVII http://www.projectseven.com Fully Automated Menu Systems | Galleries | Widgets http://www.projectseven.com/go/Elevators *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Browsers and Zooming
Well here's a guy who has done a bit of usability testing. To quote from the article: We know from user testing that users hate horizontal scrolling and always comment negatively when they encounter it. http://www.useit.com/alertbox/20050711.html Of course he could be entirely wrong but I don't know of any more credible research than his. How many people have set a window size that will make your page or my page either fall outside the viewing area or squish to the point that other usability issues come to bear Quite a few actually, now that designers tend to design for a minimum screen resolution of 1024x768 while there are still a significant number of people still using lower resolutions. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Sparber Sent: 03 July 2008 22:17 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Browsers and Zooming From: Andrew Maben [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Thursday, July 03, 2008 4:38 PM Subject: Re: [WSG] Browsers and Zooming On Jul 3, 2008, at 3:41 PM, Al Sparber wrote: an irrational fear of scrollbars When a block of text exceeds the viewport width, that means horizontal scrolling for *each line* - a royal PITA. I kid of think you are speaking for yourself ;-) If a right hand column falls outside the viewing area, it's not unreasonable to assume that a significant number of users will not bother to look. Concern for either of these is scarcely irrational fear IMHO. I think you have to first buy into someone else's usability tests. I don't. I am skeptical of many usability manifestos. That said, I'm not totally sure one way or another on this issue. What I am sure of is that I have not conducted conclusive testing, but the testing I have conducted leads me to believe, for now, that fear of scrolling is a fear that is far more prevalent among web developers than it is for the general population. As for right columns falling outside the viewing area - whose viewing area? What size window? How many people have set a window size that will make your page or my page either fall outside the viewing area or squish to the point that other usability issues come to bear? -- Al Sparber - PVII http://www.projectseven.com Fully Automated Menu Systems | Galleries | Widgets http://www.projectseven.com/go/Elevators *** 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] Firefox 3 candidate
You can still get some old versions from the Mozilla FTP site at http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ It's ludicrous that they have removed some old versions - can they really not afford the disk space? Obviously users should not be installing old versions but developers and testers still need them for testing. We download and store all the English versions but it's not practical to save all the localised versions too. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sagnik Dey Sent: 23 June 2008 11:21 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Firefox 3 candidate Hi Paul, You can download Firefox Ver 2.0 from . http://www.oldapps.com/firefox.htm This is a very good website for downloading older appz. -- Cheers to life Sagnik :: 26four79.com On Mon, Jun 23, 2008 at 3:31 PM, Paul Collins [EMAIL PROTECTED] wrote: Hi all, Thanks for your replies to this thread last week. I'm on a PC today and trying to get both versions of Firefox running, the only issue is, I can't find where to download version 2 of Firefox anymore! Mozilla have made it very hard to find previous versions Does anyone know where you can get version 2?! Cheers 2008/6/19 Paul Bennett [EMAIL PROTECTED]: select custom install and install it to another directory (something like /Mozilla/Firefox3) and the two will run side-by-side. You can do this with Opera too. :) 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] *** *** 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] The Problem of adjacent links
The rationale for this checkpoint seems to have been long forgotten, and I don't know of any user agent that has a problem with adjacent links. Nor does anyone else it seems, which is why the WCAG Samurai recommended that the checkpoint should be ignored. It certainly isn't a problem for any screen reader I am aware of. I have heard it said that it relates to some types of Braille display but no one seems to be able to provide examples. I can imagine that user agents would have a problem with adjacent links if they were relying on scraping the screen rather than reading the source, and some did work that way but I don't know any that do now. Most users are unaware of how pages are marked up so I don't think that they would have a preference for lists, vertical bars or anything else. During user testing we encounter both, and have not observed problems with either. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren West Sent: 09 May 2008 12:53 To: wsg@webstandardsgroup.org Subject: Re: [WSG] The Problem of adjacent links The reason for putting the character there in the first place is explicitly to help screen-reader users distinguish between links. It is my understanding that the fact that they are seperate links is what distinguishes between links ... Screen-reader users have said that the vertical bar is THEIR preferred character (even though this means repeating vertical bar) since it is not used for anything else and can't be confused. Prefered to a list? 2008/5/9 Stuart Foulstone [EMAIL PROTECTED]: The reason for putting the character there in the first place is explicitly to help screen-reader users distinguish between links. Screen-reader users have said that the vertical bar is THEIR preferred character (even though this means repeating vertical bar) since it is not used for anything else and can't be confused. Border is, of course, purely presentational and of no use whatsoever to screen-readers and, therefore, does not fulfill accessibility requirements. On Fri, May 9, 2008 7:31 am, Jens-Uwe Korff wrote: The most common separator used in such circumstances ... is the vertical bar...whilst it is quite wordy That's the reason why I've started *not* to use it anymore. I'm using borders instead and add the class last to the last list element to apply no borders at all. Whilst a border is slightly higher than a vertical bar it avoids screenreaders to go home vertical bar latest posts vertical bar contact us vertical bar sitemap vertical bar Cheers, Jens The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. *** 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] accessibility and brower compatibility for Kiosk mode?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 17 April 2008 15:36 To: wsg@webstandardsgroup.org Subject: RE: [WSG] accessibility and brower compatibility for Kiosk mode? Please help me with another question, with multiple list menu, we use 'ctrl' and 'Ctrl + shift' to select multiple options, how does this work with touch screen? tee Unless you have a keyboard, it probably doesn't work. Some touchscreens (try) to let you do dragging and stuff, but I think you are going to have to change your select box into a list of checkboxes, or something like that. Even on screens that do let you drag, anything as complex as multi-select is going to be completely non-intuitive - after all I don't know many 'ordinary' web users that know about multi-select without being told explicitly, they are too used to only being able to select a single item, and it is almost impossible to discover by accident. Mike Multi-select using listboxes or comboboxes is not fully keyboard accessible. It is possible to select a single contiguous range but it is not possible to select non-contiguous options. As Mike said, checkboxes are the way to go. Steve *** 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] Rogue text appears in IE6.
It's the well known IE6 duplicate text bug. http://www.positioniseverything.net/explorer/dup-characters.html _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Enslin Sent: 03 April 2008 10:51 To: wsg@webstandardsgroup.org Subject: [WSG] Rogue text appears in IE6. I've recently built a website trying to move towards more standards-compliant code. After the delight at pushing the site live my world 'caved in' (a little over-dramatic maybe) this morning when a colleague noticed rogue 'ls. text some way down the home page. Live site: http://www.londoncalling2008.com Screen-grab in IE6: http://www.flickr.com/photos/doos/2384241027/ Testing the site: IE7 - no problem FF2 - no problem Safari/PC - no problem Safari/Mac - no problem FF2/Mac - no problem ** IE6 - PROBLEM (http://www.flickr.com/photos/doos/2384241027/) Could anyone find an explanation for this? -- Rob Enslin http://enslin.co.uk *** 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] nest heading properly
During user testing I have not seen this cause any problems, particularly when only one level is skipped. It is certainly odd when you jump from an h1 or h2 to an h5 or h6, but users generally take even extreme cases like this in their stride (yes, we do come across sites like this!). In general, coding techniques are so poor and inconsistent that users have pretty low expectations and are grateful when header elements are used at all. It's difficult enough to form a mental model of a page, and in my experience users tend to note the presence of headers as separators between blocks of content but do not pay much attention to the nesting. In my opinion, consistency of use is more important. Of course this reflects the appalling state of web design as it exists now, and maybe in 5 years time standards will have risen sufficiently that users' expectations will be higher. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tee Sent: 28 March 2008 19:09 To: wsg@webstandardsgroup.org Subject: [WSG] nest heading properly My question isn't about how to nest headings properly E823 - 1 instance(s): Heading elements must be ordered properly. For example, in HTML H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Developers should not skip levels (e.g., H1 directly to H3). Do not use headings to create font effects. See http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-headers (displayed in new window). I am curious how much benefit it goes to accessibility. What ill effect it has on assistive user agents if headings are not nested properly. Semantically, I fully understand the need for proper order of heading elements, but in real world practice, I have yet noticing any site that follow this to the letter, and it's more than a challenge for a complicated columned layout that designer tends to use h3 for every bold text title. tee *** 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] Web Browser Testing and the Practicality of Testing other OSs
This kind of testing is our core business, and I have to say that these days there is very little difference when running a particular browser version on different Windows versions. One difference that comes to mind is that Windows 2000 has native 56-bit encryption, and this is not increased even when Internet Explorer 6 is installed. We frequently encounter issues (i.e. the site does not load at all) when the SSL server is not configured correctly for this encryption level even though it may work with 40-bit and 128-bit browsers. XP was 128-bit from the start. There is a High Encryption Pack for Win 2000 but I have no idea how many users have it. SP2, SP3 and SP4 for Win 2000 upgraded the encryption to 128-bit although SP1 did not. Win 2000 did not come with Flash, whereas XP came with Flash version 6r79, so the testing of the Flash detection routine would be slightly different. There were also differences in the Java Virtual Machine in Win 2000 and XP (XP SP1a and onwards don't even have a JVM) but I doubt that that is relevant in your case. Firefox behaves the same on all Windows versions but there are slight differences (usually with fonts) on Mac and Linux. These can cause knock-on effects with the layout, although they should not if the site has been designed to accommodate increases in text size. I absolutely would not ever use standalone versions of Internet Explorer for testing. I know people do, and for trivial applications you may consider that to be adequate. However, the behaviour is not the same, and the differences are not quantified anywhere that I am aware of, so you do not know if they are relevant to your application. I would be happy to take a look at your application and see if there are any areas where the OS would make a difference. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew WC Brown Sent: 26 February 2008 14:29 To: wsg@webstandardsgroup.org Subject: [WSG] Web Browser Testing and the Practicallity of Testing other OS's Hi WSG, I'm testing a custom application to see if it works in different OS's and Web Browsers. My question is there any practical reason to test different OS when you can download them on your current OS. eg. W2K Internet Explorer 5.5 vs WXP Internet Explorer 5.5 I have multiple IE but is there really any reason to use a different OS? Is the web browser going to be any different? Anyone with web browser testing experience have any advise? *** 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] PDF Accessibility
PDFs can be more accessible than was previously possible but there are lots of gotchas, and it's way too big a topic to cover in this reply. Note that by default, PDFs are not tagged, so they are only marginally more accessible than before. Maximum accessibility is obtained by tagging them, but that's where it gets hairy. To start with a lot depends on what application your document was authored in. If it was authored in Word (and a small number of other applications), any semantic structure that you have implemented by means of paragraph styles will be carried over to the PDF. If it was authored using graphical applications such as Quark and Photoshop, not only is there no semantic structure, but the reading order is likely to be wrong because these documents are frequently made up in layers with no consideration of how they will linearise. Tagging can be conducted automatically, using the Autotagger, but the results are highly variable. I have never seen a document that could be used without manual adjustment of the tags. In many cases it is actually easier to manually tag the entire document and not use the Autotagger. In fact we always do this, but that may be a reflection of the complexity of the documents we get asked to handle. If the source document does not contain semantic structure, the Autotagger uses heuristics to make a best guess. This sometimes comes close but often doesn't. There is a tendency for it to mark up multiple columns of text as tables, and background colours or images can confuse it. Both Acrobat 7 and 8 are pretty buggy, and the Accessibility Checker in Acrobat 7 sometimes reports faults when there aren't any. In our opinion the user interface in Acrobat 7 is much better than version 8 so we often use both for different parts of the job. Forms are a lot of fun. The user cannot save the document with the data they enter in the form, but it is still worth making forms accessible so they can be filled in and printed. There are ways to submit the forms online but there are significant licensing issues (it's ages since I looked into this, so I can't recall the detail). Even after making your best efforts, a PDF will not be as accessible as a properly marked-up HTML page with the same content. There are some resources out there but my recollection is that they all deal with the ideal scenario that you are creating new documents in Word or InDesign. There are some resources below, and they link to other useful stuff. http://www.brucelawson.co.uk/2006/accessible-pdfs/ http://alastairc.ac/2006/07/the-four-levels-of-pdf-accessibility/ http://alastairc.ac/2007/08/comparing-tagged-pdfs-from-office-and-acrobat/ For those who want someone else to take all these problems away, we offer a PDF accessibility service - http://www.labscape.co.uk/accessible_pdfs.htm, and we also provide training for mad people who want to do it themselves. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McLaughlin, Gail G Sent: 22 February 2008 16:57 To: wsg@webstandardsgroup.org Subject: [WSG] PDF Accessibility I have a client who discourages the use of PDF forms and files on their website because they believe that they are not accessible. Researching this on the Web, it appears that this may have been true several years ago, but that Adobe has made an effort to make PDF forms and files accessible in Adobe Acrobat 7.0 and 8.0. Are PDF forms and files created with Adobe Acrobat 8.0 truly accessible? I assume that certain protocols must be followed to assure accessibility, just as there are protocols to assure accessibility of HTML files. Can anyone direct me to a good resource detailing what protocols one must follow to assure accessibility of PDF forms and files? Thanks much, Gail *** 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] an accessible question: server-side vs client-side validation
In my experience client-side validation works fine with screen readers but you need to be careful how you present any error messages. It is increasingly common to see them slid in silently, and this is a big problem not only for screen reader users but also for magnifier users because they are both unaware of the change. I am a big fan of alertboxes for error messages. Sure they're clunky but they give an audible warning and they seize the focus so the user doesn't have to go hunting for the error message (assuming they even know that there is one). If you are forced to slide the error messages in silently, I recommend doing so at the top of the page and just above the Submit button. People have different strategies for figuring out what's going on if a new page does not load, but the most common are to return to the top of the page or to navigate backwards up the form. Error messages next to the relevant fields make it even easier for the user. You must retain the server-side validation because some people may not have JavaScript enabled so they will bypass the client-side validation. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tee Sent: 12 February 2008 05:43 To: wsg@webstandardsgroup.org Subject: [WSG] an accessible question: server-side vs client-side validation Hi, I have a question about server-side vs client-side validation. I always use a same PHP form script that works really great and it's server-side validation using condition and requirement, and I like the feature better than client-side's. A website I was working on, client wants client-side validation, something fancy, something Ajax. I like to stick with this form script because it has a great support for anti- spam; I suppose I can turn off the server-side validation if client- side validation is used, but I am concerned with the accessibility issue - I am particular curious how screen readers treat client-side validation. Thank you for you thought! tee *** 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] Styling forms
There may be specific cases where it would be right to mark up a form as a list, although I can't think of one. As a general rule it would be wrong. The argument against marking up a form as a list is that a form is not a list. A form is one or more groups of form controls, and the fieldset element is the correct means by which form controls should be grouped. Within a fieldset, paragraph elements should be used for individual form controls. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Horowitz Sent: 06 February 2008 03:38 To: wsg@webstandardsgroup.org Subject: [WSG] Styling forms I've been looking at styling forms and I'm seeing some people mark them up as ordered lists and other using paragraphs. What are the arguments for the different markup types. -- Michael Horowitz Your Computer Consultant http://yourcomputerconsultant.com 561-394-9079 *** 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] long description and its implementation
Most screen readers sit on top of whatever browser you are using. Professional screen readers can interact with JavaScript and Flash if these are enabled in the browser, although the level of support varies. In particular Flash content is often totally or partially inaccessible, although this is often avoidable with careful design. Screen readers do not read Flash content that is embedded using unobtrusive techniques such as SWFObject. I expect they would read the content that is supposed to be replaced, but I have never encountered an implementation where there was any alternate content. Does anyone have an example I can check? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Snodgrass Sent: 04 February 2008 04:20 To: wsg@webstandardsgroup.org Subject: Re: [WSG] long description and its implementation Maybe I'm confused. Do they usually have Flash installed? I thought that screen readers would default to whatever is suppose to be replaced with the Flash when using SWFObject. Maybe it defaults because the Flash isn't enabled... Though, I guess that could be wrong as well. Steve Green wrote: Such as? JAWS (which has something like 50% market share) has a high level of JavaScript support and I believe that the other professional screen readers (WindowEyes and HAL/SuperNova) also do. Free and cheap screen readers generally don't have JavaScript support. In our experience screen reader users do not turn off JavaScript. In fact they tend to use pretty much all software as it comes out of the box without any customisation. The one exception is Windows itself, where it is beneficial to enable Classic mode and make a few other adjustments, especially in Vista. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Snodgrass Sent: 04 February 2008 03:06 To: wsg@webstandardsgroup.org Subject: Re: [WSG] long description and its implementation Mostly empirical evidence, though I've read it in many reliable sources. Patrick H. Lauke wrote: Christian Snodgrass wrote: (Most screen readers don't have Javascript enabled, so this is a valid method). Just wondering if this is based on stats or empirical evidence? P -- Christian Snodgrass Azure Ronin Web Design http://www.arwebdesign.net/ http://www.arwebdesign.net Phone: 859.816.7955 *** 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] long description and its implementation
I checked www.salford.ac.uk with JAWS 7.10 and 9.0, and neither of them see either the linked image or the Flash content. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 04 February 2008 13:27 To: wsg@webstandardsgroup.org Subject: RE: [WSG] long description and its implementation Quoting Steve Green [EMAIL PROTECTED]: Screen readers do not read Flash content that is embedded using unobtrusive techniques such as SWFObject. I expect they would read the content that is supposed to be replaced, but I have never encountered an implementation where there was any alternate content. Does anyone have an example I can check? Try www.salford.ac.uk - there's a big flash movie at the start of the content area, which is put in place via UFO. w/out flash/js, there's just a big linked image there instead. 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 __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.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] long description and its implementation
This behaves the same as the Salford website. JAWS does not see either the
Flash content or the HTML site map.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Per Allan Johansson
Sent: 04 February 2008 14:06
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] long description and its implementation
Quoting Steve Green [EMAIL PROTECTED]:
Screen readers do not read Flash content that is embedded using
unobtrusive
techniques such as SWFObject. I expect they would read the content
that is
supposed to be replaced, but I have never encountered an
implementation
where there was any alternate content. Does anyone have an example I
can
check?
http://www.fruhagen.no/page?id=889
The leftmenu is a big flash. The site was blind to Google, but in the
replacement div I also print the sitemap as plain html. Google was happy and
the site was open again :)
div id=swf-leftmenu
ul
lia href=page?id=889
title=ForsidenForsiden/a/li
lia href=page?id=989 title=MenyMeny/aul
lia
href=page?id=990Bordbestilling/a/li
/ul
/li
lia href=page?id=984 title=Hva skjer hos ossHva
skjer hos oss/aul
lia href=page?id=985En fin side, noe
skjer/a/li
/ul
/li
lia href=page?id=977 title=Jobbe hos oss?Jobbe
hos oss?/aul
lia href=page?id=978Jobbe hos oss?/a/li
lia href=page?id=979Ledige
stillinger/a/li
lia href=page?id=986Kontakt oss/a/li
/ul
/li
lia href=page?id=971 title=Om Fru HagenOm Fru
Hagen/aul
lia href=page?id=976Fakta/a/li
/ul
/li
lia href=page?id=980
title=BildegalleriBildegalleri/aul
lia
href=page?id=981Bildegalleri/a/li
/ul
/li
lia href=page?id=973
title=SidekartSidekart/a/li
lia href=page?id=975
title=FeilsideFeilside/a/li
lia href=page?id=991
title=startstart/a/li
/ul
/divscript type=text/javascript
var so = new SWFObject('binary?id=44180', 'leftmenu', '223',
'545', '9', '#efefef');
so.addParam('wmode','transparent');
so.addVariable('XMLfeed', 'page?id=965%26pid=889');
so.write('swf-leftmenu');
/script
Work just fine as a good replacement. I should really update my css to make
it a little better to look at if the flash fails!
I made the same deal here: www.fridays.no
--
Per Allan
Enonic
***
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] long description and its implementation
You get nothing. JAWS goes straight from the left-hand menu to the list of three links (study, research and business) in the centre of the page. This is with JavaScript enabled. With JavaScript turned off, JAWS reads the image link. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Lauke Sent: 04 February 2008 16:08 To: wsg@webstandardsgroup.org Subject: RE: [WSG] long description and its implementation Interesting...so what DO you get? Is that with JS enabled? P -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Green Sent: 04 February 2008 14:23 To: wsg@webstandardsgroup.org Subject: RE: [WSG] long description and its implementation I checked www.salford.ac.uk with JAWS 7.10 and 9.0, and neither of them see either the linked image or the Flash content. Steve *** 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] long description and its implementation
Such as? JAWS (which has something like 50% market share) has a high level of JavaScript support and I believe that the other professional screen readers (WindowEyes and HAL/SuperNova) also do. Free and cheap screen readers generally don't have JavaScript support. In our experience screen reader users do not turn off JavaScript. In fact they tend to use pretty much all software as it comes out of the box without any customisation. The one exception is Windows itself, where it is beneficial to enable Classic mode and make a few other adjustments, especially in Vista. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Snodgrass Sent: 04 February 2008 03:06 To: wsg@webstandardsgroup.org Subject: Re: [WSG] long description and its implementation Mostly empirical evidence, though I've read it in many reliable sources. Patrick H. Lauke wrote: Christian Snodgrass wrote: (Most screen readers don't have Javascript enabled, so this is a valid method). Just wondering if this is based on stats or empirical evidence? P -- Christian Snodgrass Azure Ronin Web Design http://www.arwebdesign.net/ http://www.arwebdesign.net Phone: 859.816.7955 *** 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] Test Plans
When you talk about 'standard' or 'government' test plans, what you mean is documentation as per IEE 829. Unfortunately this is an appallingly bad standard that guarantees inefficient and ineffective testing. However, this is what most test consultants peddle because it's easy to teach and some people are impressed by huge piles of test scripts (you might have guessed I'm not). It also maximises consultants' incomes because everything takes much longer than it needs to. I have run an outsource testing company for 6 years and we never use this type of documentation. I have many other resources that may be useful so I'll contact you off-list. Steve Green www.labscape.co.uk _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Jeffery Sent: 15 January 2008 12:09 To: wsg@webstandardsgroup.org Subject: [WSG] Test Plans Hi All. Im not familiar with test plans for Websites, i have my own way of running tests that usually run of what the client wants i.e: Is the header 320px heigh? and does it expand when the font size is incremented?. I have to do an in depth test plan for an assignment, which i would also use for future jobs. Has anyone got any good resources on test plans? I'd like to see a few government ones if possible and some 'standard' or 'defacto' plans if possible. Im not sure if this topic borderlines on being removed, but i feel its standards related and most the users here work or have worked for companies that use them or they use themselves so i felt i'd get a better response. Cheers guys. I await your replies and thanks for your time. *** 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] Test Plans
I've just sent James a heap of sample test plans and stuff, but unfortunately very little of it is online because it's mostly stuff I've collected over the years in case it was ever useful (it wasn't). If you want to learn about how to do bad testing, just Google IEE 829 or ISEB. If you want to learn about good testing, read the following: www.context-driven-testing.com Everything written by Cem Kaner - www.kaner.com Everything written by James Bach - www.satisfice.com Bret Pettichord's four schools of testing - http://www.io.com/~wazmo/papers/four_schools.pdf If anyone wants to know more it's probably best to email me off-list. Steve www.labscape.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Horowitz Sent: 15 January 2008 17:54 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Test Plans I'd love to see the stuff online. I think this is a very important part of web standards. QA should not be an afterthought but an integral part of the process. Michael Horowitz Your Computer Consultant http://yourcomputerconsultant.com 561-394-9079 Steve Green wrote: When you talk about 'standard' or 'government' test plans, what you mean is documentation as per IEE 829. Unfortunately this is an appallingly bad standard that guarantees inefficient and ineffective testing. However, this is what most test consultants peddle because it's easy to teach and some people are impressed by huge piles of test scripts (you might have guessed I'm not). It also maximises consultants' incomes because everything takes much longer than it needs to. I have run an outsource testing company for 6 years and we never use this type of documentation. I have many other resources that may be useful so I'll contact you off-list. Steve Green www.labscape.co.uk http://www.labscape.co.uk -- -- *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *James Jeffery *Sent:* 15 January 2008 12:09 *To:* wsg@webstandardsgroup.org *Subject:* [WSG] Test Plans Hi All. Im not familiar with test plans for Websites, i have my own way of running tests that usually run of what the client wants i.e: Is the header 320px heigh? and does it expand when the font size is incremented?. I have to do an in depth test plan for an assignment, which i would also use for future jobs. Has anyone got any good resources on test plans? I'd like to see a few government ones if possible and some 'standard' or 'defacto' plans if possible. Im not sure if this topic borderlines on being removed, but i feel its standards related and most the users here work or have worked for companies that use them or they use themselves so i felt i'd get a better response. Cheers guys. I await your replies and thanks for your time. *** 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] semantic list with explanations
I have a big problem with the term 'best practice', especially when it is used to effectively terminate a discussion. It implies that not only is there currently no better solution, but that there never will be. I believe that the most appropriate solution invariably depends on the context, and find that the principles of the context-driven school of testing (my main profession) apply to most activities. the first two are: 1. The value of any practice depends on its context. 2. There are good practices in context, but there are no best practices. The rest are at www.context-driven-testing.com for those who are interested. As Chris has said, our context is usually that we have limited time and are designing to provide the best user experience for people with the user agents that exist now. If your context is that you have unlimited time to create an academic solution for user agents that should exist but don't, then it is very likely that you will come to a different solution. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz Sent: 11 January 2008 17:15 To: wsg@webstandardsgroup.org Subject: RE: [WSG] semantic list with explanations Thierry Koblentz wrote: Because like I said, following this logic why not using table markup to give users of other UAs (old visual browsers like IE 5 Mac, NN6, etc) a better experience too? Why just SR users? because thats a different issue. It's an issue of the user not upgrading to software thats available and thats better. The issue we speak of is the user unable to do anything about the situation themselves because there is no better software, so we should look after them if we can. User not upgrading to software that's available and that's better. Do you think it's that simple? no i don't Believe me, many people do not have that choice. I know. But someone does. If i own a business and make my staff use IE6 then thats my choice because theres something better out there - my staff can't do anything about it but i can. upgrading from IE6 to Firefox is *not* the same as trying to upgrade from NN4 or IE5 Mac. Usually, the latter requires investing money. Which is different to screen reader users who have up to date software that lacks some features. They have no choice to upgrade. Therefore they are a different group to the users of the other UA's you mention. Therefore, it doesn't follow that it's using the same logic if we use tables like you suggest. Users stuck with old browsers face the same issue. But rather than being their software that lacks some features it is their hardware (that don't allow them to upgrade to a better UA). Although i applaud your commitment, I feel your approach is very academic in nature. As someone who mostly earns their living by producing websites for businesses, I feel that it's my job to do whatever delivers the best user experience for the people who are the end users of the site. And, although I firmly believe in adhering to standards (why would I be here otherwise?), if that means using heading and paragraph tags instead of dl's then so be it. Do you mean Standards or best practice? I don't think Standards say to replace DLs with headings/paragraphs and I hope best practice do not say that either. If I think this approach should not be considered best practice it is because I believe it is more a workaround than a real solution. If you care about the end user then why not using the DOM to give SR users a better experience? The same way we use CSS to give users of visual browsers a better experience? To me, that would make more sense. If we say it is bad to use HTML for presentation (it would not be *visual* in this case, but I think the issue is the same) then why making exception for a particular UA? I posted a link to an article that shows how to turn a DL into headings and divs, but you could try a simpler approach, using a script to plug headings into the DTs or even replace the dt/dt with hx/hx. None of this is kosher, but it would only be generated markup, so I don't think it'd be a huge issue compared to the benefits for SR users and the fact that the document itself would be properly marked up (I didn't try this myself and have no clue how it would work, but I think it is worth investigating). And I don't think it's right to use these client websites as a means to make a stand against user agent vendors if it means sacrificing any of that usability. I don't think that's what I said. I didn't say we should keep using DL to force manufacturers to take care of the issue, I said why manufacturers would take care of the issue if everybody stop using DLs? Which, imho, is very different. FWIW, if my approach when writing markup is pretty much UA agnostic, it is because I rely on the two other layers to address issues. -- Regards, Thierry | http://www.TJKDesign.com
RE: [WSG] semantic list with explanations
I agree that there may be a context in which it is an appropriate solution but I don't think it is appropriate for the context of the original post. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz Sent: 11 January 2008 19:19 To: wsg@webstandardsgroup.org Subject: RE: [WSG] semantic list with explanations On Behalf Of Steve Green I have a big problem with the term 'best practice', especially when it is used to effectively terminate a discussion. It implies that not only is there currently no better solution, but that there never will be. I believe that the most appropriate solution invariably depends on the context, and find that the principles of the context-driven school of testing (my main profession) apply to most activities. the first two are: 1. The value of any practice depends on its context. 2. There are good practices in context, but there are no best practices. The rest are at www.context-driven-testing.com for those who are interested. As Chris has said, our context is usually that we have limited time and are designing to provide the best user experience for people with the user agents that exist now. If your context is that you have unlimited time to create an academic solution for user agents that should exist but don't, then it is very likely that you will come to a different solution. Hi Steve, I'm glad to see that you seem to agree that a script may be a viable solution and that using headings/paragraphs is not the only answer to this problem. -- Regards, Thierry | http://www.TJKDesign.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] semantic list with explanations
The desire for semantic purity is only one of many factors when deciding how to mark up a page. Other factors include (but are not limited to) UA support, the user experience, the time available to implement the design and the expected life of the website. I would expect a professional designer to balance these appropriately, taking into account the best interests of their customer. The ability to find the appropriate balance is what sets professional apart from hobbyists. It's easy to go to one extreme - it saves you having to think. Anyone can write semantically perfect code that validates if they don't care how long it takes, what the user experience is like and what it looks like in browsers that are not standards-compliant. If you're designing your own site and you're on a mission to embarrass UA vendors into making a better product then go right ahead. But if you're designing websites for real people to use with real user agents, you're doing them a disservice. If you're being paid for that design I would say you have no right to follow your personal preferences rather than make a professional judgement, unless your customer has given informed consent. The average life of a website is only a couple of years before it gets redesigned or scrapped. Designing for non-existent user agents is therefore futile because there's little likelihood they will come into existence within the life of such a site. To then make compromises that are to the detriment of existing user agents is absurd. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz Sent: 09 January 2008 06:58 To: wsg@webstandardsgroup.org Subject: RE: [WSG] semantic list with explanations Absolutely it is. I'm rather surprised at how badly they handle DLs, but almost zero percent of web developers use them even now (remember that standards-compliant designers represent perhaps 1% of the industry). Go back just a few years and no one at all was using them. Is it not also the responsibility of designers to design for the user agents that actually exist rather than utopian user agents that do not exist? After all, the WCAG make several references to Until user agents... which explicitly acknowledges that user agents don't yet have all the functionality that users need. In fact they never will because expectations will change over time. In another document that I can't currently find, the W3C state that it is necessary for designers, user agent vendors and the standards themselves to all move together. There's no use one of these going off in their own direction at their own pace. It's never going to be possible for all of them to be exactly in sync but that's what we need to aim for while making progress in an agreed direction. I don't think that using headings in this example is cheating at all. It's perfectly valid as other people have suggested. IMHO, the markup you suggested would be valid *only* if this succession of name/value pairs was *not* considered as a list. If it is a list, then the only proper markup is a list (imho). Remember that the purpose of semantics is to convey information effectively. There is no point in using them if they do not achieve that goal. If you care about the users you will provide semantics that 'are' useful to them, not semantics that 'should' be useful. I think a DL is the element that would convey the information the more effectively. And I guess that's why most of the posters who replied to the OP before you did, told him to use a definition lists. Because for all these posters it is the element they think would be the most semantic in regard to that content; best proof (imho) that it should be the markup of choice. Could you stand in front of your customer a justify your viewpoint to them? I don't suppose they would be terribly impressed because they want the best user experience for their customers. How can you intentionally deny them that? The same way I tell them we should not use table for layout to please people using old browsers. To me, it makes absolutely no difference. I think there should be no double standards when it comes to UAs. If you think it is important to not really follow the rules by using headings/paragraphs instead of a DL to give SR users a better experience then let's say bravo to table markup used for layout when it is done to increase user experience! -- Regards, Thierry | http://www.TJKDesign.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:
RE: [WSG] standards-compliant designers
Of course I made up that 1% figure but I don't suppose it's far out. Just look at the phenomenal number of crap websites out there. There are something like 100,000 people offering web design services in the UK (10,000 in London alone) yet GAWDS membership (which is global) is only around 500 and I believe WSG membership is similar. Those who take standards-compliant design seriously tend to be individuals producing small volumes of work, but the large volumes are typically generated by organisations that neither know nor care about standards-compliance. They are invariably tied to enterprise-scale CMSs that guarantee the code will be horrible. Likewise, ASP.Net implementations can be made to be standards-compliant but it takes a huge amount of work so most organisations just use it as it comes out of the box. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Pennell Sent: 09 January 2008 14:12 To: wsg@webstandardsgroup.org Subject: Re: [WSG] standards-compliant designers On Jan 9, 2008 2:01 PM, Andrew Maben [EMAIL PROTECTED] wrote: standards-compliant designers represent perhaps 1% of the industry is this really the figure - any sources? It's impossible to say, unless you draw a line in the sand and define what qualifies someone to call themselves a 'web designer'. Does it have to be your job title? Your business? Do you have to be paid for it? Our industry includes everyone from Zeldman to the marketing department struggling with a CMS to back-bedroom solo web agencies to the neighbour's kid with a copy of FrontPage. -- - Matthew *** 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] semantic list with explanations
I think that definition lists would be appropriate semantically but in the real world I don't know of any user agent that does anything useful with a definition list or any user group that derives any benefit from them. Certainly they make no sense when read with a screen reader because you cannot differentiate one list item from the next. I would therefore use heading and paragraphs. As ever, your decision depends on your motivation. If you care only about semantic purity and don't care about the user experience, go ahead and use a definition list. If you do care about the user experience, use headings. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim MacKay Sent: 09 January 2008 03:49 To: wsg@webstandardsgroup.org Subject: [WSG] semantic list with explanations Hello all, Just looking for a little help. I'm creating a sort of 'point form' list that goes a bit like this: 1. Pursuit of customer satisfaction We promise to pursue customer satisfaction as our main point of customer focus.blah blah blah.. 2. Pursuit of customer loyalty We promise to pursue customer loyalty as our secondary point of customer focus.blah blah blah.. What is the best way to semantically mark this up? My first guess would be an ordered list but the definitions underneath don't really allow for it. A definition list doesn't seem very appropriate either because of the wordiness of the explanations; to me a true definition list would only be a few words. Any thoughts? Thanks, Tim *** 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] semantic list with explanations
Absolutely it is. I'm rather surprised at how badly they handle DLs, but almost zero percent of web developers use them even now (remember that standards-compliant designers represent perhaps 1% of the industry). Go back just a few years and no one at all was using them. Is it not also the responsibility of designers to design for the user agents that actually exist rather than utopian user agents that do not exist? After all, the WCAG make several references to Until user agents... which explicitly acknowledges that user agents don't yet have all the functionality that users need. In fact they never will because expectations will change over time. In another document that I can't currently find, the W3C state that it is necessary for designers, user agent vendors and the standards themselves to all move together. There's no use one of these going off in their own direction at their own pace. It's never going to be possible for all of them to be exactly in sync but that's what we need to aim for while making progress in an agreed direction. I don't think that using headings in this example is cheating at all. It's perfectly valid as other people have suggested. Remember that the purpose of semantics is to convey information effectively. There is no point in using them if they do not achieve that goal. If you care about the users you will provide semantics that 'are' useful to them, not semantics that 'should' be useful. Could you stand in front of your customer a justify your viewpoint to them? I don't suppose they would be terribly impressed because they want the best user experience for their customers. How can you intentionally deny them that? Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz Sent: 09 January 2008 05:21 To: wsg@webstandardsgroup.org Subject: RE: [WSG] semantic list with explanations Hi Steve, Isn't the responsibility of screen reader manufacturers to treat DLs for what they are? Following this logic, we should be using basic table markup for layout to give people using old visual browsers a better experience. If we cheat with the markup to please user agents what's the incentive for SR manufacturers to take care of the problem? -- Regards, Thierry | http://www.TJKDesign.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Green Sent: Tuesday, January 08, 2008 8:19 PM To: wsg@webstandardsgroup.org Subject: RE: [WSG] semantic list with explanations I think that definition lists would be appropriate semantically but in the real world I don't know of any user agent that does anything useful with a definition list or any user group that derives any benefit from them. Certainly they make no sense when read with a screen reader because you cannot differentiate one list item from the next. I would therefore use heading and paragraphs. As ever, your decision depends on your motivation. If you care only about semantic purity and don't care about the user experience, go ahead and use a definition list. If you do care about the user experience, use headings. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim MacKay Sent: 09 January 2008 03:49 To: wsg@webstandardsgroup.org Subject: [WSG] semantic list with explanations Hello all, Just looking for a little help. I'm creating a sort of 'point form' list that goes a bit like this: 1. Pursuit of customer satisfaction We promise to pursue customer satisfaction as our main point of customer focus.blah blah blah.. 2. Pursuit of customer loyalty We promise to pursue customer loyalty as our secondary point of customer focus.blah blah blah.. What is the best way to semantically mark this up? My first guess would be an ordered list but the definitions underneath don't really allow for it. A definition list doesn't seem very appropriate either because of the wordiness of the explanations; to me a true definition list would only be a few words. Any thoughts? Thanks, Tim *** 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] jaws (ot?)
Read the license terms - they are very clear. You can only use the demo version to help you assess whether you are going to purchase the full version. Nothing else. You explicitly cannot use the demo version for testing your websites. Once you have decided that you are not going to purchase the full version, you cannot use the demo version any longer. It sounds like your decision whether to purchase it is not based on comparison with other screen readers, but it is based solely on the cost of the product. As such your decision is already made and you cannot legitimately use the demo version. It certainly is expensive but it's a tool of the trade that you just have to have if you want to build accessible websites. Sorry if that's not what you wanted to hear. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dwain Sent: 12 December 2007 21:35 To: web standards group Subject: [WSG] jaws (ot?) i have downloaded jaws and i get a nag screen to activate it. i checked the price for the program and $850 is quite a bit of money. there was nothing mentioned about a time limit on the program. could someone give me some additional info on this issue? dwain -- dwain alford The artist may use any form which his expression demands; for his inner impulse must find suitable expression. Kandinsky *** 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] Article: Vocalize Firefox (text-to-speech extensions for Firefox)
A year ago I started to evaluate FireVox 2.6 and had a dialog with Charles Chen, its creator. At that time there is no way I would describe it as full-fledged screen reader as it had many shortcomings. I got the impression it was really just a hobby project, and Charles said he had pretty much abandoned it in order to work on more interesting stuff. I see it is now up to version 3.4 so it will be interesting to see how it has progressed. It was certainly usable, but it bears no comparison with a professional screen reader like JAWS, which is a far superior product. OK, it should be for $1500 but people should not think that they're getting a $1500 product for free when they install FireVox. It's more akin to products in the $200 price bracket. One example of the difference is in forms where label elements have not been used, and let's face it, that's 99% of all forms. JAWS applies heuristics to identify the text that is most likely to be the label, and associates it with the form control as if a label element had been used. 9 times out of 10 it gets it right. FireVox does not do this. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 05 December 2007 04:25 To: wsg@webstandardsgroup.org Subject: [WSG] Article: Vocalize Firefox (text-to-speech extensions for Firefox) I'm wondering if anyone has tried/tested the following potentially useful extensions and if so what their opinion was/is: Two recently released text-to-speech extensions can transform Firefox into a talking Web browser suitable for users with visual impairments -- and anyone else who can use a speech interface to the Web. Fire Vox is designed to be a full-fledged screen reader in a browser, usable for daily browsing even for unsighted users. CLiCk, Speak provides point-and-click screen reading, which can be helpful for partially-sighted users or sighted users who have written language difficulties (such as dyslexia). http://www.linux.com/feature/122197 Nick *** 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] Article: Vocalize Firefox (text-to-speech extensions for Firefox)
A year ago I started to evaluate FireVox 2.6 and had a dialog with Charles Chen, its creator. At that time there is no way I would describe it as full-fledged screen reader as it had many shortcomings. I got the impression it was really just a hobby project, and Charles said he had pretty much abandoned it in order to work on more interesting stuff. I see it is now up to version 3.4 so it will be interesting to see how it has progressed. It was certainly usable, but it bears no comparison with a professional screen reader like JAWS, which is a far superior product. OK, it should be for $1500 but people should not think that they're getting a $1500 product for free when they install FireVox. It's more akin to products in the $200 price bracket. One example of the difference is in forms where label elements have not been used, and let's face it, that's 99% of all forms. JAWS applies heuristics to identify the text that is most likely to be the label, and associates it with the form control as if a label element had been used. 9 times out of 10 it gets it right. FireVox does not do this. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 05 December 2007 04:25 To: wsg@webstandardsgroup.org Subject: [WSG] Article: Vocalize Firefox (text-to-speech extensions for Firefox) I'm wondering if anyone has tried/tested the following potentially useful extensions and if so what their opinion was/is: Two recently released text-to-speech extensions can transform Firefox into a talking Web browser suitable for users with visual impairments -- and anyone else who can use a speech interface to the Web. Fire Vox is designed to be a full-fledged screen reader in a browser, usable for daily browsing even for unsighted users. CLiCk, Speak provides point-and-click screen reading, which can be helpful for partially-sighted users or sighted users who have written language difficulties (such as dyslexia). http://www.linux.com/feature/122197 Nick *** 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] Accessible likert scale (disagree/agree/strongly agree/etc) forms
I don't recommend that solution. We have tested this kind of form with a highly proficient screen reader user, and he could not understand it at all. In fact it was one of the few tasks he has ever failed to complete. This is one of those cases where marking up content so it is semantically correct does not mean it can be understood by users. I recommend using label elements for each radio button and hiding them off-screen. This was discussed at length on GAWDS very recently but I don't have time to dig out the thread. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 12:34 To: wsg@webstandardsgroup.org Subject: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms Hello All, I'm working on a Likert scale questionnaire (Strongly Agree/Agree/ Undecided/Disagree/Strongly Disagree) with 20 questions and some Googling came up with the following approach... http://www.enterpriseaccessibility.com/articles/ AccessibleRadioButtons.html ...and I was wondering what the general opinion of this or any other solutions was. Thanks, Nick *** 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] Accessible likert scale (disagree/agree/strongly agree/etc) forms
The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. Once the user has read through a few questions and realises that the structure is consistent, they won't need to listen to the whole of each label and they can very quickly skip through the form. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 22:40 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms On 04/12/2007, at 12:07 AM, russ - maxdesign wrote: Hi Nick, The sample code on this page you link to does not look ideal. As has been mentioned on this list a few times, title attributes are often ignored by screen readers. And the use of a table element to lay out the form is a little odd. Unless I am missing something, I'd say it would be much better if it marked up with standard form elements. For example (warning - code below thrown together very quickly): form action=# method=get fieldset legendThe product is a good value for the dollar/legend label for=strongly-agreeinput name=likert id=strongly-agree type=radio /strongly agree/label label for=agreeinput name=likert id=agree type=radio /agree/label label for=disagreeinput name=likert id=disagree type=radio /disagree/label label for=undecidedinput name=likert id=undecided type=radio /undecided/label label for=strongly-disagreeinput name=likert id=strongly-disagree type=radio /strongly disagree/label input name=submit id=submit type=submit value=Submit / /fieldset /form You can then use CSS (and a hammer if needed) to position these form elements exactly as you want. That does help Russ, thanks. As I said to Steve though I do wonder how much fun using JAWS or such like would be going through all that for 20 similar questions! Nick *** 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] Accessible likert scale (disagree/agree/strongly agree/etc) forms
Undoubtedly it's the cleanest way to achieve the required functionality, and there are fewer accessibility issues. However, it is less easy for a user to quickly review their answers because they have to read the text rather than just look at the physical position of the selected radio button. Also it doesn't give an indication of the trend, although this will not always be relevant. For most users it will take longer to fill in a form using select rather than radio buttons; at least two actions compared with one. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Lo Sent: 03 December 2007 23:51 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. Once the user has read through a few questions and realises that the structure is consistent, they won't need to listen to the whole of each label and they can very quickly skip through the form. What is your opinion on the idea of using SELECT mentioned by Patrick? Nick *** 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] Accessible likert scale (disagree/agree/strongly agree/etc) forms
You're right, and this is a problem we always have. Users develop different ways of approaching forms, and some will jump in and out of forms mode to make sure they read anything that is not in a label e.g. validation rules. However, in the example given, I think the legend is way too long and will deter the user from filling in the form at all. Without user testing you can't be certain what people will do, but my experience suggests that users will work out that they need to go in and out of forms mode, and that it is not unduly onerous to do so. As long as the structure is consistent they will be able to navigate quickly. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke Sent: 04 December 2007 00:00 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessible likert scale (disagree/agree/strongly agree/etc) forms Steve Green wrote: The problem with the code below is that the content of the legend will be read before every label. That makes it very difficult for a screen reader user to read it fast. I would just have the question in a p or possibly even a header element. However, if the user is in JAWS' forms mode, are headers/paragraphs not ignored (say as they're tabbing from input to input)? Sorry, been a while since I actually sat in front of a proper JAWS installation... 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 __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.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] Iframe navigation accessibility question
The accessibility issues relating to frames are often overstated, although they can cause difficulties with user agents that only support one window, such as Lynx. You can usually still use the site but it is not as convenient because you have to keep going back to the list of frames in order to access the navigation menus. We have done user testing on frame-based sites, and screen reader users had no problems. There's a bit more verbiage as the start and end of frames is announced, but the provision of frame titles can actually be helpful. The biggest problems with frame-based sites are more usability than accessibility issues e.g. bookmarking. Steve _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Leslie Sent: 21 November 2007 14:32 To: wsg@webstandardsgroup.org Subject: [WSG] Iframe navigation accessibility question Hi Folks, I have just inherited a bands website which places all of the navigation (both top and bottom links) in iframes. I don't 100% understand why the developer chose to do this unless it is emulating php includes in static html, anyway, it seems like a bad idea to me and is high on my list of things to sort out on the site. My question is: Is this as inaccessible as I fear it is? Will a screen reader be likely to have issues with it? I have to do a new version of the site around Easter next year when a new album comes out, I'm wondering whether I should spend the time fixing this version up in the meantime or whether it's issues are not as harmful as I fear. Thanks James *** 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 Maps?
Not at all. You know that the site only has 15 pages but your visitors don't. The sitemap gives the visitor an immediate indication of the size of the site, so why deny them that? It can be a big help in determining their strategy for browsing the site. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Taylor Sent: 21 November 2007 14:44 To: 'wsg@webstandardsgroup.org' Subject: RE: [WSG] SIte Maps? But even for a relatively small site having a sitemap will help some users find what they want quickly. Those people are the same ones who will scan the index of a book before flicking through the pages. I've done that on this site: http://www.2plan.com/ despite it only being 15 pages or so. Does anyone think that is overkill? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Montoya Sent: 21 November 2007 14:26 To: wsg@webstandardsgroup.org Subject: Re: [WSG] SIte Maps? On Nov 20, 2007 7:04 PM, Jermayn Parker [EMAIL PROTECTED] wrote: In coming in late to the discussion: Do we really need a sitemap? I recently read an article were it talked that if all the seo was done properly and it was smallish, you probably do not need a sitemap. I remember that article too. It was saying that a sitemap is meant to expose pages of your site that are difficult to reach for a search spider that starts at the homepage. If you have a working link structure and anyone can reach any page of your site by just following all the links, everything is already exposed and you don't need a sitemap. -- -- Christian Montoya christianmontoya.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** This message has been scanned for malware by SurfControl plc. www.surfcontrol.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] AccessResearch // Page Check
People with assistive technologies rarely benefit from 'title' attributes. They are not displayed by text browsers, they are not accessible using keyboard navigation (or devices that emulate keyboards) and they are not read by screen readers with default settings. They are only accessible to someone who uses a mouse and can hover it over the link, in which case it is not particularly difficult to go the extra step and click it. On top of that, excessive use of tooltips of any kind causes an obstacle for screen magnifier users, as they obscure a large proportion of the page even at relatively low magnification levels. So I have users very much in mind when I recommend that 'title' attributes should be used as little as possible. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Jeffery Sent: 18 November 2007 10:32 To: wsg@webstandardsgroup.org Subject: Re: [WSG] AccessResearch // Page Check On Nov 18, 2007 1:19 AM, Patrick H. Lauke [EMAIL PROTECTED] wrote: James Jeffery wrote: Not every anchor needs extra advisory information, so I don't see an issue here. The title attribute is optional, but a title can help to clearly and accurately describe a link and for a website thats based around accessibility he should be using the title attribute where needed. But his links don't need it in this case. So your saying that before a user reads the content of the home page they are expected to know whats on the My Project page? Keep in mind users who use assistive devices to browse the web might find it very difficult to navigate to other pages. You could sum up the page contents in the title so it saves the user clicking the link. Adding clarity when possibly needed is a good thing. /overAndOut *** 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] AccessResearch // Page Check
If a user wants to magnify the screen there are alternative methods for making link text bigger People don't spend hundreds of pounds on magnifiers to do something that any browser can do. Most sites would break horribly if you increased the text to even 4x its normal size, and many people run much higher magnification levels than that. Magnifiers also do much more, such as colour substitution or inversion, and of course they magnify everything including the browser chrome, not just the text. At 800x600 resolution and 4x magnification, even a relatively small tooltip can obscure nearly a quarter of the screen, and it is not always obvious how to get rid of it if the active area of the link is larger than the text. And of course there is no way to turn off the tooltips. So on balance I believe that a few people benefit from 'title' attributes, a few people are negatively impacted and they are irrelevant to vast majority of people. I therefore recommend only using them when really necessary, in which case you should really be thinking more about why your link text isn't adequate. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Jeffery Sent: 18 November 2007 19:02 To: wsg@webstandardsgroup.org Subject: Re: [WSG] AccessResearch // Page Check [quote cite=http://juicystudio.com/article/using-title-attribute.php;] Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a tool tip (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource. [quote cite=http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H33.html;] Assistive technologies provide different levels of support for speaking the title attribute for an anchor element. JAWS 7.0 will speak either the link text or the title attribute for a link depending upon a JAWS setting. This setting can be changed temporarily or permanently within JAWS. However, it is awkward to read both the link text and the title attribute for a link. WindowEyes 5.5 has a hot key, ins-E, that will speak additional information, including the title attribute, for the item with focus. Home Page Reader 3.04 will speak the the URL of the current page and title attribute of any element with focus when the control-shift-F1 keys are pressed simultaneously. Some do, some don't. I would rather provide to those that do and give the disabled a greater benifit for those that make use of the title attribute. It would be wrong *not* to use the title attribute when you could be helping others make more sense of your page. Its like saying dont think about users with older browsers, they are the minority. Every user counts. If a user wants to magnify the screen there are alternative methods for making link text bigger, there is no alternative method for a user to make sense of link text. James On Nov 18, 2007 5:44 PM, Steve Green [EMAIL PROTECTED] wrote: People with assistive technologies rarely benefit from 'title' attributes. They are not displayed by text browsers, they are not accessible using keyboard navigation (or devices that emulate keyboards) and they are not read by screen readers with default settings. They are only accessible to someone who uses a mouse and can hover it over the link, in which case it is not particularly difficult to go the extra step and click it. On top of that, excessive use of tooltips of any kind causes an obstacle for screen magnifier users, as they obscure a large proportion of the page even at relatively low magnification levels. So I have users very much in mind when I recommend that 'title' attributes should be used as little as possible. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Jeffery Sent: 18 November 2007 10:32 To: wsg@webstandardsgroup.org Subject: Re: [WSG] AccessResearch // Page Check On Nov 18, 2007 1:19 AM, Patrick H. Lauke [EMAIL PROTECTED] wrote: James Jeffery wrote: Not every anchor needs extra advisory information, so I don't see an issue here. The title attribute is optional, but a title can help to clearly and accurately describe a link and for a website thats based around accessibility he should be using the title attribute where needed. But his links don't need it in this case. So your saying that before a user reads the content of the home page they are expected to know whats on the My Project page? Keep in mind users who use assistive devices to browse the web might find it very difficult to navigate to other pages. You could sum up the page contents in the title so it saves the user clicking the link. Adding clarity when
RE: [WSG] Skip nav links, tab through
There's no reason why you shouldn't be able to tab through the links in Firefox. Links are not on the tab sequence in Safari by default, but you can turn that on in the Preferences. I have no idea if users actually do in practice. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Collins Sent: 15 November 2007 14:45 To: wsg@webstandardsgroup.org Subject: [WSG] Skip nav links, tab through Hi all, I've added a hidden skip navigation link to my site, that I want to show up when you tab through each page. I'm using the method described on the webaim site: http://www.webaim.org/techniques/skipnav/#focus Problem is, I realised that you can't actually tab through the links on a page using Firefox or Safari. I am guessing this has to do with Tabbed Browsing shortcuts?! Does anyone know a better way of doing this, so when someone tabs through your site they get the Skip Navigation link displayed? Cheers *** 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] ***
