W3C home > Mailing lists > Public > public-wai-eo-badtf@w3.org > February 2006

Re: Summary of BAD TF teleconference on Tuesday 14 February, 2006

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Sun, 26 Feb 2006 09:45:03 +0100
Message-ID: <44016A8F.8050406@w3.org>
To: Liam McGee <liam.mcgee@communis.co.uk>
Cc: BAD TF <public-wai-eo-badtf@w3.org>

Hi Liam,

Just realized that when the font-size is increased on the index page (testing in Firefox 1.5), the three DIVs in the center (Panda, Violin, Brain) do not drop down vertically but stay beside each other horizontally (see [1] for an example of what I mean by this). This makes it necessary to scroll right/left to read them. Are these not floating? Can you repair this?

[1] <http://www.w3.org/WAI/EO/Drafts/eval/tools/advanced>


Liam McGee wrote:
> Shadi Abou-Zahra wrote:
>> #1) Images of top stories as CSS (Panda, Violin, Brains)
>> - These images usually do convey some content that is related to the 
>> article. To demonstrate best practice in images and descriptions, we 
>> will do the following:
>> * Images in the (right) side bar will be assumed as purely decorative 
>> and hence will remain as CSS images with no descriptions.
>> * Images in the center top-stories section (Panda, Violin, Brains) 
>> will be assumed informative and will be placed into the HTML with 
>> short descriptions.
> Done (see attached)
>> #3) PDF leaflet needs an accessible version (or alternative)
>> - This will be removed from the before and after page.
> Changed this on the after version, Shadi to change from the before
>> #4) Need explicitly associated label for the quick menu
>> - An invisible <label> to describe the purpose of the quick menu 
>> should be implemented as best practice. More over, the contents of the 
>> menu should reflect the themes rather than repeat the left navigation 
>> bar (e.g. "articles", "tickets", etc). This will be changed on both 
>> the before and after pages because it is not really an accessibility 
>> issue.
> Done. Please note that the server action for this needs writing. Shadi?
>> #5) Document structure should start with <H1> level heading
>> - An invisible <h1> with information such as "Citylights Home Page" 
>> should be implemented. This heading should be the same as the document 
>> title too.
> Invisible headings are fine for you screen reader users, but annoying 
> for us no-mouse Opera users who navigate visually by heading - you 
> suddenly lose your focus, although you kn ow that *something* is there. 
> I would still maintain that the page h1 should be the first heading of 
> the main content, with the title giving site and page information.
> Meta tags -- guess we could state that this is part of a collection, but 
> I think this may confuse the issue between the example -- which should 
> stand alone apart from the educational information around it -- and the 
> presentation of the example.
>> #6) CSS validation errors ("display: inline-block") and warnings  - 
>> Seems like inline-block is a valid CSS 2.1 element. Shadi will look 
>> into this.
> I have my fingers crossed. The w3c css validator is throwing an error on 
> inline-block. Can find mention of it in the working draft though. But it 
> will confuse more adventurous users who validate is if the validator 
> throws up a false negative. Can we get the validator upgraded if 
> inline-block is valid to avoid any potential confusion?
>> #7) Screen reader directions and options
>> - Invisible list at the top of the page that describes the skip links 
>> to screen reader users does not show in JAWS. The reason is the usage 
>> of CSS "display: none". Need to implement this by left positioning out 
>> of the view port. Also, these direction should come after the warning 
>> which should always be the first element.
> It *was* implemented as left-positioning out of the viewport, the 
> display: none is for vision-no-mouse Opera users for whom skip links are 
> at best redundant and at worst broken. It is overridden in the next line 
> (using * html and :root to restrict the function to IE, Konqueror-based 
> and Moz-based users, but this has worked for JAWS and WindowEyes in the 
> past). The last time I implemented this (or at least a very similar 
> version) it was on Jim Thatcher's site, and it *did* work for JAWS, or 
> at least on the versions of JAWS we tested on (5.something - 5.45 sound 
> familiar? and 6.0), and on Window Eyes (v4 I think). I have tried a 
> couple of subtle changes to the implementation. Please retest, and if 
> still not working, please check my original implementation on 
> www.jimthatcher.com -- if that is working on your version of JAWS then I 
> will replicate it exactly for here. It would be nice to know what 
> exactly is upsetting JAWS though.
> Tanguy, could you tell me the version of JAWS you are using, and 
> describe the behaviour to me, if still not working, step by step?
> Other changes:
> 1) Shadi, I have changed the warning text very slightly (the addition of 
> 'a' and 'an' to the second sentence).
> 2) Would suggest reviewing the section title 'Facts' given it is now a 
> concert ticket page.
> Thanks all
> Liam

Shadi Abou-Zahra     Web Accessibility Specialist for Europe | 
Chair & Staff Contact for the Evaluation and Repair Tools WG | 
World Wide Web Consortium (W3C)           http://www.w3.org/ | 
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ | 
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ | 
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ | 
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France | 
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 | 
Received on Sunday, 26 February 2006 08:45:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:50 UTC