I attended Access U 2006 at St. Edward's University put on by Knowbility.org. As usually happens when I attend training about making electronic information accessible, I learned that some of the stuff I learned before is wrong. I also learned that most of the stuff I learned before is right. Whew! I learned some new stuff, too. Here's a summary of what I learned:
Derek Featherstone of Box of Chocolates and Further Ahead talked about Javascript. My "aha" moment was when he talked about the DOM (document object model) and how javascript interacts with it on a web page. I think I'll be able to work that out and use it soon at work.
He talked about modern javascript and how you can separate content (html) from presentation (css) from behavior (javascript). Instead of using browser detection to compensate for differences in browsers, you can just check to see if the current client understands something and if it doesn't stop the script. For example, if the browser understands "document.getElementID", it's a modern browser, so you can add the following code to stop old browsers from continuing a script:
if (!document.getElementById) return;
I also learned that you can create new content with javascript and the DOM using the following things:
document.createElement()
document.createTextNode()
A misconception that I've had about javascript is that for accessibility, when you add javascript to a page, the page needs to still work if someone has javascript turned off. But that assumes all people using assistive technology have javascript turned off. The bottom line is that, just like html and css, the javascript needs to work for people using assistive technology, too. User testing is really all that you can do to ensure that.
I heard about Macromedia Flex in the class from a student, but I need to investigate more.
Another misconception I learned about was that you don't necessarily need to add a redundant "onkeypress" event when you have an "onmouseclick" event.
I learned a little more about what AJAX is (asynchronous javascript and xml) where you can make a section of a page update without reloading the page. I think they use that on 43 Things a lot. AJAX is not necessarily inaccessible. We just have to learn about how it will affect people with assistive technologies.
James Craig from cookiecrook.com and Frog Design taught advanced CSS. I took this class 3 years ago, and it was the major "aha" moment with CSS. He really knows his stuff. That class 3 years ago spurred me on to redesign my entire site. It's not perfect, but it's better than it was before.
One thing he showed was how to separate style sheets into separate files when multiple people are working on a site. In the main style sheet, just add an @import statement to include individual style sheets:
@import "mystyle.css";
or
@import url("mystyle.css");
This could be used to separate styles for navigation, templates, content, etc.
He suggested when you make a body style, to also add the html tag like so:
html, body { whatever: xyz; }
That's for a particular flavor/version of browser that has a different background color if the window opens wider than the space the content takes up.
Recommended references:
Other tidbits:
Kelsey Ruger of The Moleskin introduced a bunch of development tools we can use to develop and test our sites. His presentation is available on his site: Web Development Toolkit.
He recommended Dreamweaver 8 and showed us some of the enhancements since MX 2004. They've enhanced code view enough that I think it's worth an upgrade.
Coding Tidbit: If you use more than on "ID" on a page with the same name, it's not going to break CSS, but it will break the DOM.
He also discussed the design process and keeping everyone involved in the process from beginning to end and making templates for the different types of pages then building the CSS around that to keep from making a monster out of the CSS. He also recommended breaking the CSS out into Core, Layout, Presentation and Navigation.
Kelsey Ruger of The Moleskin taught this class. He gave us guidance on what criteria we can use to audit a site. His presentation is available on his site: Performing Web Site Audits.
There are the regular things to audit for (accessibility, usability, search readiness), but a fourth category is "credibility." I like that idea. Some of the questions to ask to determine whether a site is credible:
A student commented that people should always put the area code on phone numbers in contact information.
Another student talked about something that I run up against at work. People complain that the search engine doesn't work, but it's not the search engine's problem... it's bad titles on pages. No search engine will index a page well that's not coded properly.
Randy Horwitz of the IBM Human Ability and Accessibility Center and Rhodes Gibson of Go9Media taught these classes.
I knew most of the stuff taught in the class, but one thing I learned that I had learned wrong before is to not put a summary on layout tables. I had learned before that you should put a summary that says "layout only", but I guess that's not right.
Randy verified that as a secondary method of labeling form fields, you can use the title attributed in the form field. This is a useful method if the layout of the form gets messed up when you add fieldsets and legends. So you can use title in the input field instead of the fieldset, legend and label attributes.
And in case Randy sees this, I'll repeat: Use "for" in the label and make it match "id" in the input field.
Answer: Yes
Of course, everyone in the class already knew that. But we had a discussion about accessibility.
You know... making sites accessible to people with disabilities also makes them easier to use for people without disabilities. Usually, it makes a site more usable. It also makes a site usable on a small handheld device. If you're a techno geek, you like that. And being a techno geek isn't even a disability. Or is it? (kidding)
Vinh Nguyen from the Disability Law Resource Project spoke. He talked about the new WCAG 2.0 (Web Content Accessibility Standards). They follow the idea that information should follow "P.O.U.R." standards:
The new standards should be done by Summer 2006. They'll be better than prior the 1.0 standards because they don't focus on HTML alone, and they provide better information about how to implement standards and why they're important.
