Uh-oh, don’t look now, but a new A List Apart article on contrast on the Web, entitled “Contrast Is King” makes note of the GrayBit tool and its use. Developed by Mike Cherim and I several years ago, this tool has been up for awhile, but it seems like it’s finally catching on as a useful tool to add to the Web developer’s arsenal. I’m excited to have been part of something that contributed to the future of the Web, in its quality and accessibility.
I’m so glad that it’s finally out! I’ve been working a long time on this little webapp, and now that all the bugs have been ironed out, we’re rolling it out into 1.0. Be sure to check it out if you haven’t already!
Special thanks goes to Bokeh of the Web Developer Forums for assistance with image processing functions (PNG and GIF transparency, specifically). I can’t say how thankful I am for his help!
On another note, GrayBit is currently selling advertisement spaces. We’re looking for ads from folks who run accessibility-aware web sites. Our rates are very fair and the ads get a decent amount of attention, so if you’re interested, let us know via the contact form at GrayBit.com!
Please check out GrayBit and let us know what you think, and be sure to link to us and spread the word about GrayBit so that everyone can enjoy color, wearing shades of gray!
Basically, it’s a PHP webapp that converts any web site into black-and-white. That’s right, even your images. This provides a great way to tell if your site has too high or too low of a contrast between its elements, and best of all (unlike other similar tools), GrayBit is interactive.
This being the beta launch, we’re still ironing out some flaws in the system. Overall, though, GrayBit performs very well. If you’re trying a site like Yahoo, Amazon, or Google, the results will be mixed at best, due to the fact that those sites use tables for layout and GrayBit is designed with its target audience — accessibility-aware developers — in mind. Ergo, we’ve chosen to make the system optimal for our target audience, rather than trying to be everything for everybody (really, no one who makes a site like Amazon is going to care what their site looks like in black and white — they already obviously don’t care what it looks like with color!)
I just wanted to take a minute and thank Bokeh from the Web Developer Forums for some help with the PNG processing functions. I was at a loss there for a couple days, unable to figure out how to get alpha transparency to work properly (due to my lack of experience with PHP and GD). Thanks to Bokeh, I was able to figure it out.
Now, for any further information, please direct your (undivided) attention to http://GrayBit.com/, where the fun goes vibrant in a completely colorless way!
Accessites is a web design showcase, but it’s not your average CSS gallery. It’s something so much more special. It’s akin to the Web Standards Awards, but on a stricter and, in my personal opinion, more organized level. Accessites has a mostly objective rating system for a web site’s accessibility, and design — the opinionated — takes the backseat for the most part. However, we are most interested in accessible and beautiful sites. We’re not just after great looking sites or highly accessible sites, we’re after accessible ones that look great. They are few and far between, but the accessible and beautiful are what we want. We hope this higher standard will cause web developers and designers alike to covet Accessites Awards, since only the most accessible and aesthetic sites will be accepted. By raising the bar, we will promote accessibility and good design — not just one or the other.
The mastermind behind this whole thing is Mike Cherim, the leader of the project. (Trust me, this guy’s chock-full of ideas.) He developed the idea, designed and implemented the site (using our Green Beast CMS, which all team members have separate logins for), and compiled the outstanding and talented team.
Oh yea, and as an example of Mike’s creativity, just look at the name, “Accessites.” It’s not just because it’s accessible + sites (though it lacks a third “s” for access-sites), but it’s also like a human race. We are the Accessites! It’s kind of like Israelites or something (but not so much like mosquito-bites). ;)
Some really cool things about this project…
If you want to learn more about our Accessites project — to become a team member (we could really use some more help) or to submit your site — visit Accessites now!
Enjoy!
At least, in a sense. “What!?!! You’re crazy!” you say. Well, for your information, according to the W3C the SPAN and DIV elements have no semantic value, except that they can be used where no semantic or structural tag exists, making them as meaningless as not having a tag in the first place (save the fact that a tag is present for structure and/or presentation, but not semantics). Therefore their only drawback is that they increase page weight. Admittedly, it is best practice to avoid using additional HTML where unnecessary, however the disadvantage of using additional HTML tags such as SPAN and DIV is minimal (page weight increase).
I said above that there is no such thing as a non-semantic SPAN or DIV in a sense. Let me elaborate on the reasoning behind that. If, by saying non-semantic, you mean that SPANs and DIVs have no semantic value, then there is indeed a such thing as a non-semantic SPAN or DIV — in fact, with that reasoning, all SPANs and DIVs are non-semantic, which makes the adjective “non-semantic” redundant (except that there is a tag in place, giving a structural, and often presentational, meaning to the element, but not a semantic one). On the other hand, in the sense which I spoke on above, if by saying non-semantic you mean that it is bad practice to use SPANs and DIVs where they are inappropriate due to their semantic value, then you are incorrect, because they have no semantic value to begin with. As a result, the statement “non-semantic SPAN or DIV” is highly redundant, since SPANs and DIVs are inherently non-semantic.
Once you understand that SPANs and DIVs don’t confuse screen-readers and other handicap-assistant software, your only reason to argue that adding an extra DIV or SPAN (or HTML comment) is a bad idea is that it increases the page weight. However, when you come to realize that the majority of a page’s weight is from its content, you’re on the losing end of the argument. The template itself can easily be between 2-10 kilobytes (this page, including its content, makes a total of roughly 4k, excluding images), and still be much smaller than a table layout’s template. Unless you’re going for a strictly bare-bones design (which would not require extra DIV or SPAN elements anyway), there should be no problem with the size of the page. If your page is 180k, following the addition of content, then instead of trying to reduce the amount of HTML in your template (unless your HTML is 50%+ of the total page weight), perhaps you should try reducing the amount of content or splitting up the content into multiple pages. There are different approaches to remedying the problem of a very heavy page, but consider the biggest source of your page weight (the content) before attempting to reduce the size of your template (and risk compatibility).
All I’m saying is there’s no reason to freak out about additional, meaningless markup for presentation — or structure. If your image replacement technique requires an extra SPAN, so what? It’s just a few more bytes. At least it’s cross-browser compatible and accounts for most, if not all, of the problems it tries to fix (for example, CSS on/images off). You may prefer to omit such meaningless tags, and that’s a good general practice, but preference does not indicate necessity. I’ll give up a few bytes of bandwidth/loading time any day to permit more accessible documents.
I have. Today. This morning. How? I got sent a newsletter. I never subscribed to get the newsletter, but I got it in this “special” case. Why? Well, it seems a link to my JavaScript and Accessibility article has been placed in their current newsletter, and they want to make sure it’s all right with me. I don’t understand why they think that I would mind at all, since it’s just a little more publicity for yours truly, but I guess it’s wise to notify the person’s content you’re linking to anyway, which is good, because otherwise I wouldn’t have known that their current newsletter linked to my article. Anyway, thanks, my Purple Top friends.
Having said all that, there are some corrections that I want to make to my three-part series of JavaScript and Accessibility. (Updating articles after they’ve already been posted at Web Reference is a very long, difficult and, I feel, unnecessary process. For that reason, I’m making the corrections here.)
My first mistake was in this sentence: “The last DTD, the frameset DTD, is essentially the Strict DTD.” The fact is, the frameset DTD is essentially the transitional DTD. It doesn’t make sense to force strict HTML in a frameset, and there is no reason for two frameset DTD’s.
Martin Kliehm was kind enough to point out another accessible technique for opening new windows. My method, on page two of part one, is a bit different from normal, whereas his is more subtle and something probably more practical for most of the people out there.
<a href="page.html" onclick="openWin(this.href, 'myWindow',
'width=400,height=400'); return false" target="_blank" title="Open page in a new window">open page</a>
Instead of using “document.write,” Martin has used the TITLE attribute to describe the functionality of the link. Also, my method could work better by having used “this.href” like Martin, instead of outputting the same address twice (something I definitely should have seen).
Martin also pointed out that events should be device-independent, so I should also use the onFocus and onBlur events in addition to the onMouseOver and onMouseOut events.
In part three, the DHTML menu that I explained is not 100% accessible, according to Mr. Glen Hennessee, a Web Reference.com reader who sent me an email on the subject. He claims that in order for the menu to be completely accessible, it must be navigable without any kind of pointing device (e.g., a mouse). Keyboard navigation with the menu doesn’t work on submenu items. The solution to this would be to add the :focus pseudo-class and have it operate the same way that the :hover pseudo-class does. I haven’t written code for it to work like this, but I doubt it’s very difficult, since I already did explain everything and how to use it. Plus, if you’re disabled in such a way that you can’t use a mouse, I think you’ll be using some sort of browser like a screen-reader or text-only browser, which would only see the unordered list.
If you’ve found other errors, please let me know about them, so that I can explain them better. Thanks for reading!