- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Mon, 14 Apr 2008 17:45:51 -0700
- To: public-comments-WCAG20@w3.org
- Cc: "Sheena McCullagh" <sheena.mccullagh@blueyonder.co.uk>
---------- 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? 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. 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. 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. 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. 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. 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. 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. 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 Tuesday, 15 April 2008 00:50:48 UTC