[WSG] RE: WCAG 2.0 compliance and best practise on the Skip to function [SEC=UNOFFICIAL]

2012-06-05 Thread Steve Green
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]

2012-06-05 Thread Steve Green
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

2012-06-05 Thread Steve Green
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.

2012-03-19 Thread Steve Green
 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?

2012-03-07 Thread Steve Green
-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?

2012-03-07 Thread Steve Green
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?

2012-02-21 Thread Steve Green
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?

2012-02-21 Thread Steve Green
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

2011-07-18 Thread Steve Green
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?

2011-07-16 Thread Steve Green
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

2011-06-24 Thread Steve Green
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

2011-03-26 Thread Steve Green
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

2011-01-27 Thread Steve Green
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

2011-01-27 Thread Steve Green
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

2011-01-27 Thread Steve Green
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

2011-01-26 Thread Steve Green
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

2011-01-25 Thread Steve Green
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

2011-01-25 Thread Steve Green
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

2011-01-24 Thread Steve Green
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

2011-01-22 Thread Steve Green
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

2011-01-22 Thread Steve Green
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

2011-01-21 Thread Steve Green
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

2011-01-20 Thread Steve Green
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

2010-11-10 Thread Steve Green
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

2010-11-08 Thread Steve Green
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?

2010-10-26 Thread Steve Green
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

2010-10-22 Thread Steve Green
-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

2010-10-14 Thread Steve Green
-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

2010-01-03 Thread Steve Green
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 browsers——IE7 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

2009-11-01 Thread Steve Green
 

-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

2009-10-28 Thread Steve Green
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

2009-10-28 Thread Steve Green
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

2009-10-28 Thread Steve Green
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

2009-10-25 Thread Steve Green
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?

2009-10-12 Thread Steve Green
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

2009-08-26 Thread Steve Green
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

2009-08-19 Thread Steve Green
-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.

2009-06-03 Thread Steve Green
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

2009-04-14 Thread Steve Green


-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?

2009-03-25 Thread Steve Green
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?

2009-03-25 Thread Steve Green
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?

2009-03-25 Thread Steve Green
 

-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

2009-03-12 Thread Steve Green
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

2009-01-15 Thread Steve Green
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

2008-12-31 Thread Steve Green
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

2008-12-12 Thread Steve Green
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

2008-11-28 Thread Steve Green
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

2008-11-28 Thread Steve Green
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

2008-11-20 Thread Steve Green
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

2008-11-20 Thread Steve Green
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

2008-11-20 Thread Steve Green
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

2008-11-20 Thread Steve Green
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

2008-11-20 Thread Steve Green
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

2008-10-18 Thread Steve Green
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

2008-10-03 Thread Steve Green
 
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

2008-09-29 Thread Steve Green
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] Looking to source a JAWS version

2008-09-24 Thread Steve Green
 
 in our attempts to improve our accessibility we want to get a version 
 of JAWS.

 It's not easy to master all of the JAWS commands so try the 40 minute 
 demo first.

Hi Ben,

It's great that you are wanting to do accessibility testing, I assume in
addition to following standards[1].

There is a fairly steep learning curve for full-fledged screen readers, and
an infrequent tester cannot get a sense of what it's really like to use a
screen reader without observing a regular screen reader user. Thus, I
personally[2] find it's easiest and better to find regular screen reader
users (that is, someone who is blind) for your main development and testing,
and then use a simple free/cheap voicing browser or screen reader only for
in house testing of specific things as you develop.

For more on this, see:
* http://www.uiaccess.com/accessucd/involve.html

Regards,
~Shawn

[1] http://www.w3.org/WAI/intro/wcag.php
[2] Note this email is not representing my employer, even though I'm on this
list with my employer email address.

-
Shawn Lawton Henry
about: www.uiAccess.com/profile.html
phone: +1-617-395-7664
email: [EMAIL PROTECTED]
-


Hi Ben,

Shawn is quite right, and I find that testers and developers use screen
readers totally differently from the way that 'real' users use them because
they don't know any different.

We provide screen reader training for testers and developers, which teaches
them not only how the software is used, but how screen reader users create a
mental model of web pages and the strategies they use for navigating within
them. Without that knowledge there is little value in doing the testing
yourself.

Steve Green
Director
Labscape Ltd
[EMAIL PROTECTED]
www.labscape.co.uk

-



***
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???

2008-09-04 Thread Steve Green
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???

2008-09-03 Thread Steve Green
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

2008-08-15 Thread Steve Green
 

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

2008-08-14 Thread Steve Green
 
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

2008-08-14 Thread Steve Green
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.

2008-07-08 Thread Steve Green
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

2008-07-07 Thread Steve Green
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

2008-07-07 Thread Steve Green
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

2008-07-03 Thread Steve Green
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

2008-07-03 Thread Steve Green
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

2008-06-23 Thread Steve Green
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

2008-05-09 Thread Steve Green
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?

2008-04-17 Thread Steve Green
 

-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.

2008-04-03 Thread Steve Green
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

2008-03-28 Thread Steve Green
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

2008-02-26 Thread Steve Green
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

2008-02-22 Thread Steve Green
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

2008-02-11 Thread Steve Green
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

2008-02-05 Thread Steve Green
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

2008-02-04 Thread Steve Green
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

2008-02-04 Thread Steve Green
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

2008-02-04 Thread Steve Green
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

2008-02-04 Thread Steve Green
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

2008-02-03 Thread Steve Green
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

2008-01-15 Thread Steve Green
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

2008-01-15 Thread Steve Green
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

2008-01-11 Thread 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.

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

2008-01-11 Thread Steve Green
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

2008-01-09 Thread Steve Green
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

2008-01-09 Thread Steve Green
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

2008-01-08 Thread Steve Green
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

2008-01-08 Thread Steve Green
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?)

2007-12-12 Thread Steve Green
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)

2007-12-05 Thread Steve Green

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)

2007-12-05 Thread Steve Green
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

2007-12-03 Thread Steve Green
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

2007-12-03 Thread Steve Green
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

2007-12-03 Thread Steve Green
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

2007-12-03 Thread Steve Green
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

2007-11-21 Thread Steve Green
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?

2007-11-21 Thread Steve Green
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

2007-11-18 Thread Steve Green
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

2007-11-18 Thread Steve Green
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

  1   2   >