Isn't it lovely? (ok, I was fighting with blogger over posting code, so I just did a screen capture... it's kind of a blurry gif, sorry about that....) This screenshot shows what the meta for my site looks like.
...and I was kind of lazy with some parts of the meta... especially the LC subject headings part, I know there are better ones...)
...and there are actually 2 kinds of meta in this project: stuff input by dreamweaver (keywords) and DC. The reason I am including meta even though I am using a NO ROBOTs tag (which tells the web seach engine & other spiders to go away & not index)
is that
- accessibility checkers need some of this meta,
- HTML checkers need some of this meta and
- whenever I release this for public, I will change the robot tag but not have to worry about anything else. ;)
In the process of ensuring that my project meets minimal guidelines for accessibility and that the code itself validates, I hit a roadblock with the code validation. The accessibility part is not the issue; I was able to create a text only page using UGA's text only generator (fabulous!) and I made sure to use alt tags throughout. I do think one big advantage with CSS is that there is just not as much in the way of code on the actual html pages, which makes accessibility that much easier, I would think. (No tables and little code formatting in the actual pages...)
My CSS validated beautifully using the W3C validating tool. However, when I tried to validate the HTML, it kept failing. Why? Well, it has to do with the metadata that I have chosen to use (part of which is required for accessibility issues) I very much want to use LC's Dublin Core (DC). DC is kind of an old friend and well, being a librarian, part of me feels that I should ALWAYS follow LC policies and practices... well, they do not have policies and practices for everything in life ;) but at least for metadata!
If you duplicate any fields in the metadata, the HTML checkers will just toss it out. Thankfully, this was a relatively easy fix for me. I just had to delete my (title)(/title) tags and use the DC title tag. Kind of a scary thought.... (btw, I can't seem to use brackets in blogger as it conflicts with the templates somehow....) , but it seems to work just fine and validates. I also considered throwing out the html and just going with xhtml, but thought I would just stick with what I have at the moment. ;)
I am very keen on accessibility as a practice, although in my personal projects, I am not as good a steward of good design as I should be... I sometimes forget the alt tags when I posting images in my online art journal (it does have full meta and it is framed in CSS, but I'm not sure that it would validate... I supposed I should give it a try...)
For additional reading and reference, I've enclosed some additional links at the bottom about CSS and accessibility. Now on to my article....
In Stephen's article, which is in response to a discussion posted on NODE stating that " Lines will have to be drawn and limits to accessibility will have to be defined - that's just the nature of the medium," he agrees that accessibility is an important issue which needs to be defined. He goes on to state that "[u]niversal access involves rather more than including image and link descriptions... In some cases, the technology does not yet exist to enable full accessibility. In other cases full accessibility will be either impractical or impossible."
Considering this article was written in 1998, it is interesting to me that things have not changed alot. Yes, standards have become more common and people do talk about accessibility on occasion, but the simple fact that different browsers STILL render code differently is kind of amazing. It would seem like the web has been around long enough now, that standards should be the highest priority. Because without standards, there is no consistency, and without consistency, user experiences are different (sometimes bad, sometimes good), designers have to work harder to try to address browser issues, and companies who create software or hardware to interact with the Internet have to take into account how (or even IF) their product will work....
After reading this article I do feel a little better about my problem in getting my code to validate!
PROJECT PROCESS: I did add a blog where users could add their own thoughts on creativity. I also tried to add explanatory text in terms of the intent of this project. My project validates (HTML, CSS) and my project meets accessibility criteria for WAVE and Watchfire.
REFERENCE: Downes, Stephen. (1998). in Stephen's Web, Downes, S. (2005). http://www.downes.ca/cgi-bin/page.cgi?post=271
CSS and accessibility
Accessibility features of CSS, http://www.w3.org/TR/CSS-access
CSS Accessibility, http://www.tsbvi.edu/technology/accessible-css.htm
Word Count: a whole bunch
No comments:
Post a Comment