The Firefox Web Developer Toolbar (Full Version)

All Forums >> [Web Development] >> Accessibility



Message


Nicole -> The Firefox Web Developer Toolbar (8/2/2005 3:49:47)

Hi everyone,

I've spent some time this afternoon checking this template by validating the XHTML, corrected a few things and then turned my attention to the "Cynthia says" "WAI" and "508" validators using the Firefox Web Developer Toolbar.

With a little help from Elizabeth Castro's book "HTML for the World Wide Web with XHTML & CSS 5th Edition", I've managed to receive the message at the top of both the WAI and 508 reports "Passed Automated Verification".

All of my templates still use tables for layout, this one being no exception, I'm yet to learn how to use CSS for layout, but i'm nearing the point where that will occur.

My questions are: How can I be receiving a "pass" for this site when it uses tables for layout? I know other aspects of Accessibility which i haven't implemented on this template yet, so how can it pass? I'm getting a few N/A and N/V results validating with Cynthia, so does this entitle me to call this template Accessible at some level?

Nicole




caz -> RE: The Firefox Web Developer Toolbar (8/2/2005 5:42:11)

Accessibility Checks: Version 0.1 ( Tidy on the Fx Web Dev extension, preferences set at level 1)

line 13 column 1 - Access: [6.1.1.1]: style sheets require testing (link).
line 147 column 8 - Access: [6.1.1.2]: style sheets require testing (style element).
line 18 column 1 - Access: [5.1.2.1]: data <table> missing row/column headers (all).
line 28 column 4 - Access: [2.1.1.1]: ensure information not conveyed through color alone (image).
line 28 column 4 - Access: [1.1.2.1]: <img> missing 'longdesc' and d-link.
line 81 column 8 - Access: [2.1.1.1]: ensure information not conveyed through color alone (image).
line 81 column 8 - Access: [1.1.2.1]: <img> missing 'longdesc' and d-link.
line 92 column 10 - Access: [2.1.1.1]: ensure information not conveyed through color alone (image).
line 96 column 7 - Access: [1.1.2.1]: <img> missing 'longdesc' and d-link.
line 129 column 9 - Access: [2.1.1.1]: ensure information not conveyed through color alone (image).
line 129 column 9 - Access: [1.1.2.1]: <img> missing 'longdesc' and d-link.
line 139 column 93 - Access: [1.1.6.2]: audio missing text transcript (au).


In the IE AIS Web Accessibility Toolbar you can get a WAVE visual check on your page, which suggests a heading rather than bold for "Welcome to this website". There are also other tests on this plus simulations of your page for the 'ageing eye' and other conditions.

But apart from the coding warnings, you also have to use your own judgement in manual checks. For example, with the warning at the top about testing style sheets, I am assuming that if they work as they should and that the content is usable when all styles are disabled, then it validates. I have not been able to verify that, though. ( Probably something, somewhere explains this!)

Automatic validation does return items such as this, 11.4 / (k) Option C - Check for an Accessibility Policy Link within the document.N/V. This means that it has not been verified. If you have such a link, then you can cross that manual check off.

Tables can be described as accessible when care has been taken to add labels etc. Tailside will expand on that I expect [;)]. You could add an explanatory note to the effect that the template has passed the automatic validation of "....", or what ever to cover yourself.

I look forward to a discussion on this topic too.




jaybee -> RE: The Firefox Web Developer Toolbar (8/2/2005 6:07:30)

Tables will validate if you've made them accessible.

Ideally tables should only be used for data but realistically, most sites use tables for layout, they've been around as a medium for a lot longer than css. Whilst not ideal, your visitors will be delighted to find they've been made as user friendly as possible.




Nicole -> RE: The Firefox Web Developer Toolbar (8/3/2005 3:06:39)

Okay you guys.

I think I've had a good day, I feel like I've had a good day on the accessibility front, but being the novice, I expected to run my pages through some sort of W3C type validator and receive errors, correct them and the somehow end up with an Accessible site and have an icon I can stick on it.

I’ve started with the template I’ve mentioned above as it’s a pretty simple design and according to the Hermish page that Tailslide has mentioned in her Useful Links, this page passes at AAA and 508 Levels. According to the Watchfire WebXact site it passes at AA Level and 508, and on the W3C WCAG site I can’t see any validator to run it through, only a description of what the checkpoints are and if I believe I’ve covered them, then I can use one of their icons on my site.

This has left me a little confused, not that I’d stick an icon on a template, but if making a site accessible is as easy as it has been today then I’ll do my site tomorrow and if I can get it to pass at any level I’d like to put an icon on my site. So which one? Which icon? I guess I’m just asking for reassurance that I’ve tested this template against the right things and that I’m interpreting the things I’m reading correctly as I don’t want to claim pages I create are accessible to a particular level when they’re not.

Edit: p.s. The other thing which is bothering me is my pre-conceived notion that a site using tables for layout can't pass at accessibility tests at any level.

Nicole




Nicole -> RE: The Firefox Web Developer Toolbar (8/3/2005 3:32:23)

Thanks also Caz for running my site through the things you’ve mentioned. I’ve downloaded both the IE toolbar and the Firefox Tidy thing today, Isn’t the Firefox Tidy fabulous? (Can I just say though that it takes me for ever to find where these things have added themselves in the Web Developer toolbar. It took ages to find that fangs had put itself in the tools drop-down, Foxy Voice had put itself in the bottom right of the screen etc. I wish they told you where it was going to go.) I don’t use IE at all for anything other than to visually check my pages, do you think it’s a good idea to use the IE toolbar now also, or is it the same as the Firefox one?

I too received those messages you posted above when checking my page, the three that had me confused were:

style sheets require testing
ensure information not conveyed through color alone
<img> missing 'longdesc' and d-link

I’m pretty sure I don’t need them though unless you guys think otherwise? Do I really need a long description of an image? Not on a template but on any other image? Isn’t that just when an image contains important information that isn’t available elsewhere within the site?

I’ve also downloaded NoteTab today, and used that to ftp some pages to my server. The includes still seemed to work okay, I think that was the only FP feature that I was worried about not working when ftp’d instead of publishing. I also found NoteTab handy for removing the height and width elements that FP wants to keep adding to images. I know they still appear in the template link I’ve provided in this thread, but if you look at temp26b.htm in the same directory you’ll notice they’re gone for all images except the banner.

Hope I haven’t confused anyone, if possible I’d appreciate some guidance on when to ignore such messages as Caz mentioned in her post and the ones I’ve re-posted in this post.

Nicole




Tailslide -> RE: The Firefox Web Developer Toolbar (8/3/2005 4:04:37)

Hi Nicole

I wouldn't worry about londesc as it doesn't have great browser support currently (to my knowledge). Just use a reasonable description in the alt tag - if you think it's a bit long then maybe try a title as well.

The "stylesheets require testing" bit - maybe they're referring to testing it at the W3C? Only thing I can think of anyway.

Making sure information isn't conveyed by colour alone is quite important (I've still got work to do on my sites with this). Just imagine your site in black and white - does it still make sense? Can you still find the links? If so then you're fine.

The thing with accessibility that tends to stump people - me included - is that it's not like HTML or CSS where you can shove it through a definitive checker at the W3C and KNOW absolutely that it's valid and A OK. There are checkers for accessibility but as you've found out they can be a teeny bit confusing! I remember testing one of my sites and getting loads of warnings for things that weren't even on there - they were precautionary warnings just in case I had a flash animation etc etc.

In my opinion the current accessibility checkers (with the possible exception of Cynthia which I personally quite like) are best used as indicators only - gross error checking rather than definitive yes/no answers. If you do something really silly they'll pick it up.

So much of this is personal opinion at the moment but anyway - you remember that list I stuck in the access keys fighting thread? Well that's roughly speaking my own checklist -

valid code
label everything
does text-size scale up?
skip links
reasonable contrast between background/foreground
accessibility statement if possible
try not to rely on JS or provide alternative
make everything tabbable
make sure it makes sense with no CSS

Probably forgotten something there but hey... This is just my personal list - If I've done everything there then I'll be reasonably sure that my site is accessible. I'm still not going to stick an icon on it though!

I'm rambling again - but I think my point was that accessibility is to a degree personal interpretation of the WAG stuff - if you read the recommendations and have them in mind when you build a site then you're fine.





caz -> RE: The Firefox Web Developer Toolbar (8/3/2005 6:42:15)

I too have been unsure about the stylesheet testing thing until I had a look at the Hisoftware guidance doc that I mentioned in the useful links FAQ above. Next time that you use Cynthia for WAI checking download the pdf at top right, it's a handy guide to the automatic verifier checkpoints, with good explanations.

From that I have decided that I was right all along - if the document reads sensibly when you disable all styles (Web Dev toolbar), then it has been tested successfully. Like so many of the suggested manual checks, it boils down to common sense and if your claim for accessibilty is challenged then you can outline such actions in your defence. The procedure for accessibility validation is so loose compared to html and css that many find it confusing because we are not told what to do in detail. It's not a straightjacket of tests and answers - oohh, we have to think[:(]

I have interpreted the coloured information requirement a little differently than Tailslide in that I will add title tags where I think that text would be useful too. See? Get more than one designer together over these issues, then there is more than one way to achieve accessibility heaven.

The IE AIM toolbar would be useful for you Nicole because it contains different things to the FX one - I especially like the simulations where you can see your page as someone who has colour blindness or weak eyesight will. They also inlcude simulations of conditions such as glaucoma and diabetic retinopathy, although I don't see much you can do about that visually except recommend Fx and FoxyVoice. And, of course it is an Australian product.

BTW, I use Foxy Voice to check that my text reads well and alter punctuation to do that. Amazing what a comma here and there will do[;)]





spitfire -> RE: The Firefox Web Developer Toolbar (8/6/2005 9:12:48)

quote:

Edit: p.s. The other thing which is bothering me is my pre-conceived notion that a site using tables for layout can't pass at accessibility tests at any level.

Hi, Nicole
I'm new here but I have been producing accessible web sites for a l o n g time.

Tables are not recommended for layout but tables, as such, are not forbidden. The automated tests cannot pick up what your tables are used for, but, because they know there are tables on your site, they throw up a warning and ask you to verify manually. For instance Cynthia reports this about your template:
quote:

5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
Rule: 5.3.1 - Identify all Layout Tables.
Note: Layout TABLE Element found at Line: 23, Column: 3.
Note: Layout TABLE Element found at Line: 26, Column: 6.
Note: Layout TABLE Element found at Line: 31, Column: 2.
Note: Layout TABLE Element found at Line: 37, Column: 3.
Note: Layout TABLE Element found at Line: 55, Column: 6.
Note: Layout TABLE Element found at Line: 60, Column: 1.
Note: Layout TABLE Element found at Line: 71, Column: 1.
Note: Layout TABLE Element found at Line: 133, Column: 9.
Note: Layout TABLE Element found at Line: 136, Column: 12.

5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.

To assist with visual verification, we recommend that you refer to the detail of checkpoint 5.3 for locations of elements that apply to this checkpoint.

If you follow the links to the guidelines in the Cynthia report, you should be able to figure out what it's all about. Tables should primarily be used for data and css positioning for layout. Having said that, look beneath the skirts of the Royal National Institute of the Blind's web site: http://www.rnib.org.uk. You will have to go a long way down to find any code... wonder why they did that? but you will see a lot of tables (deeply nested ones at that) have been used for layout.

If you must use tables for layout, then you *should* add a summary to the table. Why not something like "this table does not contain data, as it should, but it has been used to layout the page as a temporary measure while I'm learning how to do it in the correct/modern/up-to-date way". OK quite a lot of irony there, not aimed at you at all, but you get my meaning, I hope[;)]




jaybee -> RE: The Firefox Web Developer Toolbar (8/6/2005 9:31:09)

Welcome aboard spitfire, you should get on nicely with Tailslide. [:D]

quote:

this table does not contain data, as it should, but it has been used to layout the page as a temporary measure while I'm learning how to do it in the correct/modern/up-to-date way


Actually that really isn't a bad idea. People are far more likely to forgive shortcomings if you're upfront about the whole thing. Humour is a great pacifier.




Mojo -> RE: The Firefox Web Developer Toolbar (8/6/2005 11:09:15)

Lest OF members get confused - that may be a good idea for a site that has limited economic purposes, but don't put something like that on a site where you expect the visitor to hand over their credit card number.




spitfire -> RE: The Firefox Web Developer Toolbar (8/6/2005 13:36:18)


quote:

ORIGINAL: jaybee
People are far more likely to forgive shortcomings if you're upfront about the whole thing. Humour is a great pacifier.

I couldn't agree more and I had a thought about a disclaimer for a commercial site.

quote:

People with poor eye-sight:

We know you want to increase the text-size in IE and have allowed you to do that just a bit so you can see how it breaks the screen. If you increase the text-size in Firefox, we hope find it as hilarious as we did. We have made a vitally important design decision to put almost all of the textual information into images, but don't worry because all that text is repeated in alt tags. You only have to hover over the pictures of text to read what it says. It is not our fault that the IE "tool-tip" text cannot be increased in size and we have nothing whatsoever to do with the fact that Firefox does not display alt text at all.

We regret, therefore, we cannot allow you to cancel your contract with us merely because of the shortcomings of a couple of browsers, that between them only cover about 95% of the surfing public. And our lawyers say the same thing[sm=rotfl.gif]


Note: just people who do not see quite as well as they used to. How many millions of potential customers is that?




womble -> RE: The Firefox Web Developer Toolbar (8/7/2005 6:26:37)

[img]http://www.ddeaf.org.uk/forum/images/smiles/smiles2/rofl6.gif[/img]

Nice one!
Welcome aboard Spitfire BTW!
As for those who don't see quite as well as they used to, you're right, with an aging population we're talking millions.




spitfire -> RE: The Firefox Web Developer Toolbar (8/7/2005 7:13:56)

Is that you, nephew?
Uncle Bulgaria, here.
Well you already know I'm one of those millions - got the specs, got the grey hair, now where did I put my teeth? [image]http://easy.go.is/hubs/octo/okto_oldguy.gif[/image]




womble -> RE: The Firefox Web Developer Toolbar (8/7/2005 7:22:21)

OMG! Great Uncle B!!!! How's life down on the Common? Much nicer than those draughty burrows up here in sunny Derbyshire, though I fear you may also be losing your marbles dear Uncle, I'm your neice - don't you remember?

Meanwhile, back on-thread...the current site I did for a voluntary organisation is by no means fully accessible, but all the members of the group know the accessible one's on the way, and I try to put regular updates on the site about the progress of the re-design.




spitfire -> RE: The Firefox Web Developer Toolbar (8/7/2005 7:36:45)

quote:

I fear you may also be losing your marbles dear Uncle, I'm your neice - don't you remember?

Well there are so many of you and you young things all look alike to me. Never mind losing the thread - now I've lost my marbles as well as my zFrame.[;)]




spitfire -> RE: The Firefox Web Developer Toolbar (8/7/2005 7:41:50)

quote:

Meanwhile, back on-thread...the current site I did for a voluntary organisation is by no means fully accessible, but all the members of the group know the accessible one's on the way, and I try to put regular updates on the site about the progress of the re-design.

That's a good way of doing it. Up front, honest and you have a plan.[image]http://easy.go.is/hubs/05_dec/dec_update28.gif[/image]




Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
6.054688E-02