- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 17 Apr 2008 09:58:33 -0500
- To: sheena.mccullagh@blueyonder.co.uk
- Cc: public-comments-WCAG20@w3.org
Please find responses to your recent questions below Please let us know if this addresses your issue. Thank you Gregg Vanderheiden Co-chair. > > ---------- Forwarded message ---------- > From: Sheena McCullagh <sheena.mccullagh@blueyonder.co.uk> > Date: Mon, Apr 14, 2008 at 5:35 PM > Subject: RE: Comment 2476 (and indirectly comment 2376 > To: Loretta Guarino Reid <lorettaguarino@google.com> > > > Hi, > > Thank you so much for listening and making the alterations that you > already > have. In essence everything is there, just a few points of a practical > nature and unfortunately, unless I'm reading things very wrongly, it > would > seem that the new, very beneficial, items you have added to 1.4.8 now > contradict certain aspects of 1.4.3 (see items 5 and 6 below): > > 1 Sufficient techniques - first requirement - numbers 1 through 4, > shouldn't they have the word OR at the end? Likewise as 8 is now the > last > in the list, shouldn't it lose it's OR? RE Comment #1: Thanks. We have now fixed that as per your suggestion. > > 2 One thing that concerns me is that all the items in this list talk > about > what to do, or not do, in CSS. Nowhere can I find it mentioned that if > you > are not doing it in CSS, you can't do it in HTML either. As horrendous > as > it sounds I know people and web sites out there that look at what the CSS > does/doesn't do, then inappropriately over-ride these items in HTML using > style=. I work for a large organisation and we use a content management > system with each area being responsible for it's own web pages. There > are > several of the people who input data who are following WAIG only under > sufferance (one actually told me that we should be allowed to make a web > site look and perform how we want it to, then teach disabled people to > make > the best use of it they can). Others, often writing in isolation on > small > web sites, sometimes genuinely don't understand what the guidelines are > getting at and are so entrenched in the idea that every colour has to be > coded that when they read, for example, '2. Specifying borders and layout > in > > CSS to delineate areas of a web page while not specifying text and > text-background colors', their brains are going to follow the line of 'OK, > borders and layout in CSS only, that must mean I specify the text and > background colours in HTML.' Those who want to ignore WAIG, but are > being > compelled to follow it, can take the line of, 'Well it only says I can't > do > it in CSS, it doesn't mention HTML, therefore I can comply by not coding > text and background in CSS, but still do what I want by using HTML > instead.' > > Bim eluded to this same concern in comment 2376 - '* Any specified > foreground and background colors are in CSS, not HTML (future link) OR '. > The reply was 'since user agents or users' style sheets can override > colors > specified in CSS or HTML, we did not include ", not HTML." '. Yes that's > true, but the whole point of the additional items you added as a result > of > my last email was to stop web writers coding the colours for background > and > text for specific page areas by any means, however you only specify CSS. > > In G156 the first example states 'A Web page is designed using HTML and > CSS > to specify the foreground and background colors' Bearing in mind what > I've > just said above, that actually reads as if it's OK to specify colours in > BOTH HTML and CSS. > > And yes people really are that daft or devious. > RE Comment #2: CSS refers to the use of CSS in a style sheet or in a style attribute within HTML document. So specifying colors by using CSS style attributes in HTML would be the same as specifying thing in a style sheet as far as WCAG is concerned. If an author can not use CSS for some reason, then there's nothing in WCAG 2.0 that would prohibit them from specifying color in HTML. The problem in this case should be addressed in the user agent. We are currently working separately on the user agent aspect so that you would be able to get what you need. > 3 As you know I'd have sooner that you removed G156 altogether, but as > it > seems to be staying in there, shouldn't item 3 - 'Providing an additional > stylesheet that does not specify colors for the main content body (future > link) [2476]' be tied to it. The only reason there would be to need the > additional style sheet was if G156 had been followed, ie all colours > specified and if all the colours are specified, then, to my mind it > should > be a requirement to provide the alternative stylesheet. > RE Comment #3 We have noted your comments so that we can use them when these techniques are written up later on. > 4 In a similar vein to 2, ie web writers not understanding, is it > possible, > maybe via a 'future link' to state that the link within the web site to > the > additional stylesheet, and any description to what it is and how it works, > is contained in a web page where colours (and text size) are not > specified. > Many times I've come across web sites with wonderful information on how > to > change colourings (and text size) in the web browser or even a selection > of > colours (and text sizes) to click on within the page that will then be > applied across the whole web site, but the instructions are contained in > pages where the colours (and text sizes) are already specified. > > How are the people the information is aimed at supposed to read how to > change things if the page with the instructions on how to make the > changes > has the colours (and/or text sizes) already specified to a combination > they > cannot read? With colour selectors it's even worse. If you have to > over-ride the specified colours within the browser to actually read the > page, the various selections all change to those colours set in the > browser > so you can't see what you're supposed to be picking anyway. Even the BBC > site with it's wonderful accessibility information falls foul of this. > The > general instructions as per the link in G156 have all the colours > specified > and the colour picker is in a link from the home page called 'customise > your > home page' (URL doesn't change, so cannot give you a direct link), which > has > the page colours specified and when you over-ride, the colour options > become > those of the browser. > RE Comment #4 Our conformance would require that all information meet the guidelines - including instructions. If they don't conform on the default page - they would on the alternate page and the path to that page needs to conform as well. > 5 I apologise as this is something I've only just noticed. (I have to > read > your guidelines in the specified colours, ie black text on a white ground. > If I over-ride in the browser to my optimum colours of blue text on a > white > ground I loose the additional visual clues of colour signifying certain > page > sections or amendments, eg the new added text and the changed text. > Unfortunately I do tend to misread when reading black on white, so I can > only apologise for not noticing this earlier and hope that you will allow > me > a little leeway. The only reason I noticed it now was because I was > comparing the amendments you have just added to 1.4.8 to see how they > fitted > in with 1.4.3 (see also 6 below).) > > G148 - example 1 'Author specifies neither text color nor background. > They > also do not use CSS. As a result the user can set his browser defaults to > provide the colors and contrasts that work well for them', can be read in > two ways. Originally I took the sentence 'They also do not use CSS.' to > mean that they do not use CSS to specify the colours, but it could mean > that > the web site doesn't have a CSS at all. I think it needs clarifying and > hopefully you meant it to be taken the way I originally took it. > > It would, I feel, be a tremendous shame if a Double A automatic pass, > could > only be that if the site didn't have a style sheet at all. And thinking > logically on from that, if it does mean that G148 applies only if the > site > has no CSS at all, then sites that have style sheets and are complying to > the new Triple A sufficient techniques that you've added, would appear to > fail 1.4.3 because they cannot meet G18 and/or G145 due to the fact that > if > you are allowing browser settings to determine the colours, it is > impossible > to guarantee that the browser settings meet the minimum 5:1 and 3:1 > ratios > respectively. > > 1.4.3 does seem to be either specify all, or specify none, which goes > directly against the new Triple A (and highly appropriate) sufficient > techniques of 1.4.8. > > Example - this is the archery club web site I've written, I believe I > pass > 1.4.8 first requirement by complying to point 2. However as I don't > specify > any text, link or background colour nor text size, but do use CSS, I > can't > pass G18 and G145 and it would seem, having re-read G148 that I don't > pass > that either. Therefore I fail the Double A 1.4.3, while meeting the > related > part of the Triple A 1.4.8 - http://www.bristolanddisabledarchers.org.uk/ > > Somehow that doesn't seem right. > RE: Comment #5 You say that you lose the color information when you do your settings. This is why we have 1.4.1 (Use of Color) and why the techniques used to show diff-markup include "[begin add]," "[begin change]," etc. So you may lose the colors but they are redundant with other markup so you don't lose any information. You also were worried that your example site would fail 1.4.3, 1.4.6 and 1.4.8. In fact it would pass them. There is no way that an author can be held responsible for the contrast ratio after a user has changed the colors. > 6 Following on from the above point, all .gov.uk websites have been > ordered > to be Double A compliant by December 2008 or they will lose their right > to > have a .gov domain name (http://www.headstar.com/egblive/?p=55), well > that's > the theory anyway. If that happens the Double A guideline which deals > with > colour, ie 1.4.3 has to be complied with and taking into account what > I've > said in point 4 above, it will mean that people like myself will have > tremendous problems. Is there any way of changing 1.4.3 to show that > it's > actually better to do a combination of both as per the new sufficient > techniques for 1.4.8, or at least stop it being a fail for 1.4.3 if > people > do use a combination. I would suggest amending the description sections > of > G18, G145 and G148 by adding in a new paragraph, preferably at the > beginning: > > 'Please note that it is acceptable, and for people with dyslexia and > other > cognitive impairments preferable, to specify colors for the text and > background of certain areas of the page, while not specifying text and > background colors of the main content. See Understanding Success > Criterion > 1.4.8. Where you are specifying colors, you must make sure that you > maintain the applicable minimum contrast ratios.' (Make 'See > Understanding > Success Criterion 1.4.8' a link to > > http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20080310/visual- > audi > o-contrast-visual-presentation.html) > > The procedure section of G148 would also, I feel, need to be amended as > currently it talks about all text colours and all background colours. > RE: Comment #6 We are adding the following to the understanding doc: " It is sometimes helpful for authors to not specify colors for certain sections of a page in order to help users who need to view content with specific color combinations to view the content in their preferred color scheme. Refer to Understanding SC 1.4.8 for more information." We are also adding a "related technique" link from G148 to G18 and G156. > 7 When is WAIG 2 likely to come into force? The reason I ask is the > above > comment of all .gov.uk sites being Double A compliant by December 2008. > If > the new guidelines come into force too close to that date it's going to > be > impossible for the sites to comply and the government is going to have to > shift the date. > RE: Comment #7 We will be getting WCAG 2.0 out as quickly as we can. > 8 Finally a general thought. The guidelines are very technical in their > content, as they need to be, but it does sometimes make them difficult to > follow. An organisation in the UK, took the WAIG 1 document, split it > into > three separate documents, Single A, Double A and Triple A, gave a plain > English type summary of each point and provided a link back to the main > document. I've passed these guidelines on to many people and they've > said > how easy they are to use and how much faster it is to locate any > particular > point you want. I suspect that they are not the only organisation to > have > done this and I was wondering, rather than everyone re-inventing the > wheel, > if w3c itself might consider providing something similar for WAIG 2 once > they come into force. > > The following is a copy and paste of a section of their Single A document. > The numbers themselves are the links back to the full guidelines on your > web > site.: > > . 4.1 Clearly identify changes in the natural language of a > document's text > and any text equivalents (e.g., captions). > . 6.1 Organize documents so they may be read without style sheets. > For > example, when an HTML document is rendered without associated style > sheets, > it must still be possible to read the document. > . 6.2 Ensure that equivalents for dynamic content are updated when > the > dynamic content changes. > . 7.1 Until user agents allow users to control flickering, > avoid causing the > screen to flicker. > . 14.1 Use the clearest and simplest language appropriate for a > site's > content. > > And if you use images and image maps (Priority 1) > . 1.2 Provide redundant text links for each active region of a > server-side > image map. > . 9.1 Provide client-side image maps instead of server-side image > maps > except where the regions cannot be defined with an available geometric > shape. > > And if you use tables (Priority 1) > . 5.1 For data tables, identify row and column headers. > . 5.2 For data tables that have two or more logical levels of > row or column > headers, use markup to associate data cells and header cells. > > Yet again I've gone on much longer than intended. There again, until I > started writing this email, I hadn't envisaged including the items in > points > 5 and 6. > RE: Comment #8 While we agree that specification language can sometimes seem complex, it is important that it include enough detail to be both testable and implementable as a specification. The Working group expects to do ongoing work with the Education and Outreach Working group to develop education and training materials related to WCAG 2.0 after it becomes a Recommendation. > And once again thank you for doing all you have already done. > > Sheena > > > > > -----Original Message----- > From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] > Sent: 11 April 2008 18:25 > To: Sheena McCullagh > Cc: public-comments-WCAG20@w3.org > Subject: Re: Comment 2476 (and indirectly comment 2376 > > > On Sun, Mar 23, 2008 at 6:27 PM, Sheena McCullagh > <sheena.mccullagh@blueyonder.co.uk> wrote: > > Hi, > > > > Not sure whether this is a formal objection, some of what you have done > has > > made things better, but one major change, ie G 156 has made things much, > > much worse and will largely hamstring dyslexics like myself and to a > certain > > extent others who need specific colour combinations. > > > > Firstly, thank you for removing the requested sections, that is a great > help > > to those of us whom need specific colours. > > > > Now to the problems (suggest solution right at the bottom, rationale is > in > > the body of this email): > > > > Both I in 2476, and Bim Egan in 2376, were trying to explain that the > only > > easy way that dyslexics (myself included) and others with cognitive > > impairments can get the colours we need is for the web writers to NOT > > specify colours, ie G148, which has now been added into 1.4.8 > (Sufficient > > techniques). I rather rambled, Bim was more succinct: > > > > 'If authors DO specify all foreground and background colors, it is > virtually > > impossible for users to select their preferred, or required, choice, > without > > also losing visual clues to menu bars etc. Colour is an important aid > to > > recognising menu content when reading is difficult. > > > > Shouldn't the first sufficient technique ask authors to refrain from > > specifying inessential foreground and background colors for substantial > > blocks of text?' > > > > I stated that: > > > > 'Bullet point four - this is the only one that really works,'. > > > > Unfortunately at the time both Bim and I were commenting this bullet > point, > > ie 'Using a technology that has commonly-available user agents that can > > change the foreground and background of blocks of text (General, future > > link) ', had not been written up, it is now G 156. At the time I did > not > > appreciate that this meant we would have to over-ride specified colours. > I > > do not feel that anyone could possibly have known this as: > > > > 1 It is in effect virtually the same as the old bullet point one, (now > the > > amended bullet point 3) > > > > 2 It is not generally anything to do with web writing. It is > exceedingly > > rare, in my experience, for a web writer to over-ride these controls so > in > > most situations control is purely down to the browser (and in the case > of > IE > > 6, the system settings) the person uses and therefore it is nothing the > web > > writer is 'using', as per first word of the guideline. > > > > 3 If you over-ride specified colours in FF and Netscape most Java > Script > > pop-up boxes and drop-down menus become unusable. Pop-up boxes gain a > > transparent back-ground, so super-imposing the text of the box on the > text > > of the page and the drop-down menus either go transparent or gain a > > dark-grey, and unchangeable background. I have good screen shots of > this > > phenomenon occurring across a range of sites, which I am sending to you > via > > a separate email. (Not attaching to this one just in case it makes the > file > > size too large). Ironically enough FF is the only one of the browsers > that > > has a built-in dictionary, a real boon for we dyslexics when filling in > > forms, however it is often when we are trying to complete forms that we > have > > the JS issues described here. IE doesn't have these JS issues, but > doesn't > > have a dictionary either. So over-riding becomes a real no-win > situation > > for us. > > > > 4 It is, as I understand it, impossible to actually pass this > guideline > > because IE 6 works completely differently to IE 7 in relation to > setting > > background colours. In effect, if you pass for IE 6, you fail for IE 7 > and > > vice versa. IE 6 had a well known issue where it wouldn't over-ride > > background colours in the browser unless the same background colour had > also > > been selected in the system settings. This caused tremendous problems > for > > people needing accessibility settings when using public access > computers > in > > cyber cafes, public libraries etc. Some web sites managed to code > their > > pages so that they corrected the IE 6 problem, but in doing so, when IE > 7 > > was released those pages now showed the problems in IE7 that had been > > present on the majority of sites in IE 6. Unfortunately in the UK vast > > swathes of public access machines are still on IE 6. It is therefore > unsafe > > to quote IE as allowing colours to be changed in the browser without > > specifying which versions of IE will and won't. For an example, view > the > > following site in both IE 6 and 7. Try and over-ride the background > colour > > in the browser alone. This was one site which corrected the IE 6 fault, > but > > now doesn't 'work' properly in IE 7. For the best effect set the > browser > > colours to yellow text on a black background, ie the 'common' Visually > > Impaired combination - > > http://www.firstgroup.com/ukbus/wales/swwales/home/index.php > > > > When I commented that this was the only one that works, I had thought > you > > meant a non-Java based equivalent to 'Providing a multi color selection > tool > > on the page for foreground and background colors', as I already knew > the > > information in points 1 to 4 above, it never crossed my mind that you > could > > possibly mean over-riding specified colours, but it appears that you > do: > > > > Examples > > > > > > > > > > A Web page is designed using HTML and CSS to specify the foreground and > > background colors. The user sets their own colors in Internet Explorer > 7 > and > > they can view the content with their chosen foreground and background > > colors. > > > > > > A Web page is designed using HTML and CSS. There is a link on the page > to > > instructions on how to set colors in various browsers. > > > > This is the worst possible case scenario and completely counteracts the > > benefits of G148. Under no circumstances should G156 be used as a way > to > > pass this criteria. > > > > Within G156 you have given a link to the BBC accessibility pages. > Living > in > > the UK and the BBC being our main TV channel, I know this site well. I > > agree that their accessibility information is second to none (but even > they > > don't comment on the above IE 6 problem). However, when you actually > try > to > > apply the settings to their web site as a whole, it becomes unusable, > as > it > > does with large numbers (vast majority?) of web sites. > > > > View their home page - http://www.bbc.co.uk/ without over-riding > specified > > colours, then over-ride them, it doesn't matter in what combination, > just > > the act of over-riding makes the whole page unusable, especially in FF. > > Graphics disappear and writing superimposes on existing graphics to > make > the > > text unreadable. This phenomenon is exacerbated if you also need large > size > > text as they have failed to allow sufficient room for text expansion > (try > 32 > > point in FF). We dyslexics, and others who need specific combinations, > find > > this again and again with web sites. Over-ride should only be used as > a > > very last resort, yet you are recommending that colours are specified > > meaning that over-ride would have to be used at all times. Ironically > G > > 148, is the only guaranteed way to pass a double A criterion, yet G156 > is > a > > triple A. Theoretically Triple A should be better than double A, but > in > > this case the converse is true. > > > > Try this on your home page as well - http://www.w3.org/ While it > doesn't > > fall over in the same way that the BBC one does, all visual clues of > banner > > colours etc are lost. These additional visual clues are essential to > > dyslexics, something both Bim and I pointed out to you, but you > > mis-understood in your reply to Bim 'We agree that it is important not > to > > specify some but not all of the colors.' and 'Specifying all foreground > and > > background color attributes of any given element in CSS', when Bim had > > clearly stated that authors should refrain from this (see first quote > in > > this email). > > > > You seemed to understand the same comment when I made it, but declined > 'We > > did not include the proposed, "Specifying foreground and background > colors > > of banners, features and navigation in CSS while not specifying > foreground > > and background colors of the main content of the page in CSS and/or > HTML > > (future link)" in 1.4.8. We felt that it could not be listed as a > sufficient > > technique because, if we are understanding it correctly, it would make > it > > difficult for users who need to change the foreground and background > colors > > for the entire page to do so.' > > > > That comment is decidedly interesting. If you are saying that > specifying > > part of a page makes changing colours difficult, what is G 156 doing in > > there as a success. It's no more difficult to change part of a page > than > it > > is to change all of a page, you do exactly the same in the browser > settings > > regardless of the amount you are trying to change. > > > > I accept that those who need specific combinations across the whole > page, > eg > > Visually Impaired people using gold text on a black ground, would have > to > > over-ride if any part of the page colouring was specified and the > attendant > > problems that causes, eg BBC site and JS listed above. However, I > cannot > > see web writers accepting that they are not allowed to specify any > colours > > and what's more, that creates problems for dyslexics with the loss of > > attendant visual clues. > > > > The whole point Bim and I were making is that peripheral items eg > navigation > > bars should have colourings specified, but leave the main text areas of > the > > page unspecified. As someone who is dyslexic and has spoken to many > other > > dyslexics, short of a web site offering a Java type selection tool > where > we > > can specify specific blocks, eg navigation, headers etc, the suggestion > Bim > > and I both made is the best possible solution. Most dyslexics can > manage > > small amounts, eg navigation, in any colour combination, but need our > > specific combinations to read the text body of the page, ie the main > > content. Small web site would often not have either the skill and/or > > resources to provide such a selection tool, but could create perfectly > > accessible, from a cognitive disability perspective, web sites by > combining > > the current items 2 and 3 in sufficient techniques first requirement, > yet > > currently these two are mutually exclusive. > > > > The following web site is largely the model I would recommend, OK they > have > > made errors in that there are places where link and heading text are > > specified and backgrounds aren't, but in the context I'm talking about, > the > > main body text and background can be changed to any colours without > needing > > to over-ride within the browser. This means that we keep our > additional > > visual clues of coloured headings, navigation and separator bars but > can > > still read the body of the page. The site is a very large one so these > > additional colours are essential to readily tell what part of the site > you > > are in. However, if you over-ride the specified colours, we loose > these > > essential additional clues (and in certain places have the JS problems > see > > screen shots in separate email). Try a variety of combinations and you > will > > see what I mean about the ease with which colours can be set: > > > > In FF (1.5 and 2) Tools/Options/Content/Colours - uncheck 'Use system > > colours', then set the four boxes to any colours you desire. Select OK > > twice and the page will have changed colour. Please choose at least > one > > combination with a background other than white. Now do the same, but > > over-riding the specified colours, ie following the BBC instructions > and > > look at the difference. > > > > Please also try IE 6 and 7 again over-riding and not over-riding. The > BBC > > instructions give how to over-ride, for the not over-riding test, > simply > > ignore the accessibility tab instructions. In IE 6, you will see the > > problem of the background not changing for the specified sections of > the > > page. > > > > Here is the link - > > > > http://www.bristol.gov.uk/ccm/content/Leisure- > Culture/Libraries/invitation-t > o-save-money.en > > > > I'm sorry this has rambled on so long, but this is a subject > exceptionally > > dear to my heart, it is something I live, both as a dyslexic and a web > > writer. > > > > Please, I beg you, remove G 156 and amend the sufficient techniques > first > > requirement to allow sites to combine items 2 and 3 as suggested above. > > > > Sheena McCullagh > > --------------------------------------------- > Response from Working Group: > --------------------------------------------- > First, we would like to thank you for your detailed explanation and > examples of the issues. We have added three new sufficient techniques: > > 1. Specifying text and background colors of secondary content such as > banners, features and navigation in CSS while not specifying text and > background colors of the main content. (future link) > > 2. Specifying borders and layout in CSS to delineate areas of a web > page while not specifying text and text-background colors. > > 3. Providing an additional stylesheet that does not specify colors for > the main content body > > We have also added User Agents notes and additional description to > G156 to describe the problems that may occur if G156 is used > inappropriately. > > Thanks again for the interest that you have taken in these guidelines. > Could we ask you to let us know whether or not you are satisfied with > this response by Wed, April 16? > > Loretta Guarino Reid, WCAG WG Co-Chair > Gregg Vanderheiden, WCAG WG Co-Chair > Michael Cooper, WCAG WG Staff Contact > > On behalf of the WCAG Working Group > > > > >
Received on Thursday, 17 April 2008 14:59:25 UTC