Hello,
I just read up a good bit about the act on section508.gov, but wanted to hear first hand from some developers who have designed a site that is 508 compliant.
My main question is, is it very time consuming to design/built a site within these specs? We are currently writing a proposal for a 15 page website, and want to make sure we cover ourselves as far as the cost goes.
Thanks!
If you have a good designer / developer, it shouldn’t cost anything extra (most designers should automatically do it), while it’s not a legal requirement for commercial websites at the moment, it’s likely to become a requirement rather than a fanciful enhancement in the future. Making a website accessible just means the professional is doing their job properly and their not falling into the kind of pitfalls that (quite frankly) a beginner would hiccup over. If you want the best case scenario I would go with WCAG rather than Section 508 for compliance as WCAG is endorsed and run by the W3C and Section 508 is aimed more towards government institutions. That said, in answer to your question… if you let the designer know you need it to validate in that manner they should be able to (if their not already doing so) fairly easily. It requires very little effort or time to someone who knows their trade, it’s just making some rudamentary checks to lower the usage barrier. 
Alex.
Thanks for taking the time to give a detailed reply. I actually am head web guy at my company so that would be me doing the designing. The company we are proposing a redo for requires the site be built with 508 in mind. They do receive state funding and are a state run program so i am assuming this is the reason for it. They are a “workforce investment board” so having all walks of life able to use their website is a must, and somewhat of a legal issue I assume. They stressed the ability to be able to have a “large text” option for the site.
Thank you again
Assuming the site is correctly coded, and CSS controls the text size using ‘relative units’ and the at least starts at 100% of a browser default theoretically it covers text size.
Ironically they [section508.gov] use pixel units that are relative to the viewing device though I suppose that’s due to legacy and bugs with older browsers.
However, peculiarly it uses tables for layout and propriety markup. 
Having run against section 508 rules just with plain old testing (for example with Cynthia Says), I have run into problems. These problems aren’t usability problems, but issues like what Robert mentioned above.
For example, there’s simply a rule that all in-body script elements MUST have a noscript tag. If your Javascript is written unobtrusively, this is a great way to make it obtrusive, with a tag that may or may not even appear on the user’s screen (depends on how they are blocking scripts). Doing something that breaks your page in order to comply with a specific, government rule sucks balls.
If you are normally accessible- and usability-aware, as Alex said there shouldn’t be any extra work involved (all your other sites have no excuse anyway : ), but there may be a bit of extra work checking for specific rules.
So, read the rules, make sure you’re following them as you go. I’d love to say, follow WCAG2 (which basically just lays out scenarios that your site has to pass, technology-agnostic), but if you must be 508-compliant, you must follow it to the letter. The above-linked tool will check for the kinds of things a robot can check for, which helps. When you’re finished, you may want to run your site past some other developer unfamiliar with your site to look for errors you cannot find because you’re too used to the site.
I agree. Coding / designing a site that is section 508 compliant is simply about extra education not extra work or cost. It does not take any additional time or money to do 90% of accessibility work. There are always several different ways to skin any cat and you want to make those choices with accessibility in mind. If you’re already building websites with best practices in mind, you’ll probably find that you’re already doing most of the things you need to do to make your site section 508 compliant.
A note on the Javascript comment: I recommend following separation of concerns. That’s not an accessibility practice (though it is highly accessible), it’s a best practice. For your Javascript, that means keeping everything as managable as possible by using one script tag for each .js file you call in, these should be the last XHTML elements before your </body> tag. I recommend it for many reasons, mostly related to keeping your sanity while programming Javascript. However, it also eliminates the need for noscript tags because your page - as is - is what you would have put inside the noscript version, and the Javascripts from the .js files make modifications to that. If Javascript is not active, they aren’t applied and people get the page which solves both usability and the legal 508 compliance issue.
Having run against section 508 rules just with plain old testing (for example with Cynthia Says), I have run into problems. These problems aren’t usability problems, but issues like what Robert mentioned above.
Automated accessibility checkers like Cynthia are well known for being poor substitutes for manual checking of websites Stomme. While the W3C validator has a just cause for existence as it checks the syntax of the known specification (to find obviously detectable flaws) - accessibility isn’t about code or content… it’s about the site (and something much more than a web checker can handle). Those checkers have been created as a poor-man’s “quick fix” to attempt to automate something which computers have no ability to undertake effectively. Until we live in the world of the Terminator movie (where machines have the AI to understand contextual value and human responses) those tools are generally a bad idea - though they do at least get people thinking about accessibility.
Automated accessibility checkers like Cynthia are well known for being poor substitutes for manual checking of websites Stomme.
Not sure why you’re telling me this, Alex.
I was just confirming what you had said about having problems with Cynthia (or as you called it “plain old testing” - remember that other people view these posts, the last thing we want is someone thinking… I just want to test it quickly, if it’s out of the box testing then that must be a good option) 
Hm, you got me thinking about Cynthia’s reports… I should have done this sooner:
The “errors” it reports are not true! Cynthia is not the only tool who does this, either (HiSoftware does this too).
Section 508 does NOT require a NOSCRIPT tag where there is a script (which is great, because it would be a very very bad thing on all my sites who do actually have <script> tags in the body… they have no text equivalent, because they are written to be unobtrusive in the first place, and an enhancement).
I found Jim’s page again… he had a side-by-side comparison of WCAG1 and §508: http://jimthatcher.com/sidebyside.htm the relevant area is part 6.3
It seems the tools add extra encumbrance to our code I guess in order to help the tools keep developers in line.
Stomme, a bit of background, Cynthia Says and Accverify were developed by Rob Yonaitis, the founder of HiSoftware. So that is why the errors are the same. I know Rob made these due to a twitter conversation about this when HiSoftware put out a new tool. Here is a post by Rob talking about CS.
Cool, Ryan… I wanted to post the very bottom of that:
That was interesting material. I did want to caveat all that with Alex’s comment, though. Accessibility is a very difficult issue to manage with application logic. It’s not like XHTML and CSS which have defined logical specifications; if you’re XHTML doesn’t validate at W3C and your CSS won’t validate at Jigsaw, there’s something wrong, you fix it, and then your code is correct. Accessibility checkers don’t work anything like. The measure of accessibility is not a spec but the goal “is it usable and accessible to the audience of the website”. That can’t be translated into a spec and so you HAVE to deal with accessibility manually. The checkers are a nice way to pick up some hints about what you can do to improve your page / design, but you have to work with them and learn what they get wrong, what they get right, and what they just plain miss. one of the most important universal design issues is to ensure that all your link text and heading text is descriptive and semantic. As I think someone around here said, we’re going to have to wait for the Terminators to take over before computers can even detect that kind of problem, much less suggest a solution.