Keith W. Bell
The Keith W. Bell site, at first glance, appeared clean and professional, albeit perhaps fittingly plain. Once we started exploring more deeply, kicking the site’s tires and looking under the hood, so to speak, we quickly came to the conclusion that this is one top-notch piece of work. If you derive pleasure from looking at well-structured code and thoughtful features not overdone, you’re going to love it. And if you need the Keith W. Bell site to be accessible: it’s access granted.
We love this site, but is it perfect? Well, no, we did find some of flaws. We felt the dotted underline link styling could cause some confusion as it’s very similar to the default style associated with the abbreviation element and others. We also felt the link styling when receiving focus was somewhat insufficient. Another flaw was the contrast ratio of the color used for the main navigation menu’s link text. They clearly fall below minimum thresholds for text that size. Considering how well put together this site is, we were a bit disappointed by these oversights. How disappointed? Let’s put it this way: If these issues didn’t exist, this site would have most assuredly gotten our rarely-presented Classic award. We were torn with indecision.
Plain may describe the site’s looks, but that adjective fails to capture the parts you don’t see. The semantic structure is exemplary. Use of headings, use of lists — all impressive. And more. The positive attributes of this site run deep. As just one example, visitor support offers myriad options and avenues. Custom error pages run the range it seems as we were able to request 401 and 404 pages, both well done. The accessibility and site help page is actually helpful and informative. Really impressive through and through.
What also impressed us was the level of effort that went into the submission itself. To see what we mean, check out these Accessites submission pages that were obviously created explicitly for the occasion. Never have we seen such care and attention to detail poured into a submission. And that same care and attention to detail was also poured into the site itself. Sure, we saw some issues, like those noted above, and the fact that the excellent handheld style sheet wasn’t offered as a style option in the document header and was only user selectable, but all-in-all we were extremely pleased to be able to inspect, grade, and finally award this site.
The Keith W. Bell site was crafted by Keith Bell/December14.biz and following review was deemed eligible for an Award Level of: “Quality Universal Design.” Congratulations Keith!
Mike Cherim responds:
Posted: February 10th, 2009 at 10:10 pm →
Awesome job, Keith. I do hope we can keep the link to your submission documents active.
Joe Dolson responds:
Posted: February 10th, 2009 at 11:12 pm →
Congratulations, Keith! This was definitely one of the most accessible sites we’ve seen in quite a long time.
Karl Dawson responds:
Posted: February 11th, 2009 at 8:07 am →
An exemplary submission, Keith. Congratulations on the award!
David Zemens responds:
Posted: February 11th, 2009 at 9:32 am →
Terrific piece of work!
You set the bar awfully high for the rest of us, which is a good thing. Keep up the great work!
Keith Bell responds:
Posted: February 11th, 2009 at 4:47 pm →
Thanks to all for the fine review and the kind comments made so far — notification of the award arriving in my inbox really made my day.
To Mike and the Accessites team, maybe I could follow up on a few points.
1. Submission documents. Yes Mike, I’ll be happy to leave these up for a while for anyone who may be interested.
2. Text link styling. I take your point about the dotted underline. I wonder though if you could clarify your thinking about the link style when receiving focus being insufficient. The underline style changes as well as the text colour, which seemed distinctive to me, but I am keen to learn if there are users for whom this does not provide sufficient differentiation, and how it affects them.
3. Menu text contrast ratio. Yes, I confess this is a matter I wrestle with sometimes, and I’d like to hear the views of visually impaired people for whom contrast is an issue. There’s no question that for body text, there has to be adequate text/background contrast. And while I reject the oft-held notion that web sites can’t be accessible and good looking, there are situations where visual aesthetics and purest accessibility, if not exactly mutually exclusive, are tricky to reconcile. I feel that navigation menus constitute one such example, as they are part of the site “chrome” and are often more colourful than the body text area. Originally I styled these links as blue, but felt they were distracting and drew the eye away from the main content. I wanted to “de-emphasise” the links to the non-active pages. So I moved to grey, switching to emboldened and high-contrast red on hover/focus, which I felt was a decent compromise. I have taken the view in the past that if a menu is clearly recognisable as a menu, then so long as either the normal or the hover/focus link state has good contrast, then it isn’t too serious if the other state has lower contrast. Visitors with impaired vision will at least find links readable either in the initial state, or when they hover over or focus on them. For screen reader users, Braille display users, or users of character (text-only) browsers, then colour and contrast are not relevant. However I’m very open to be shown any flaws in my logic.
4. Handheld style sheet. I mentioned this in the submission documents. The handheld style isn’t only user selectable; rather it is user selectable in addition to being “auto-discoverable” by the user agent. Although not linked by a LINK tag in the document HEAD element, it is imported by the master.css style sheet. If a handheld user agent properly complies with web standards, then it should apply the handheld styles instead of the standard screen styles automatically — this is demonstrated by Opera when in small screen rendering mode, which gets it right. But as I said in my notes, I’m not sure that there really are many properly standards-compliant mobile user agents, which is why I provided the extra user option of selecting it manually. If anyone can tell me that there are mainstream mobile browsers that do not apply the handheld styles using my importing strategy, but which will apply the handheld styles if I LINK to the stylesheet in the HEAD, then I’d like very much to hear about them — my knowledge of mobile browsers is limited, and I’m quite prepared to re-think my linking methods for style sheets. Or did you perhaps mean linking in the HEAD as an alternate style sheet? Again, I’m not sure if many or any mobile browsers provide for selecting alternate style sheets through their own user interface. Heaven knows, there are few enough desktop browsers with that facility. I’d be grateful if anyone could provide some enlightenment.
I would like to see the graders’ comments, if you could get them to me. While my grasp of accessibility issues might be better than the average bear, I am constantly learning — and eager to learn — more of the minutiae. In that regard, I think the graders’ comments would be helpful.
Thanks again for a great review!
Mike Cherim responds:
Posted: February 11th, 2009 at 5:24 pm →
Hi Keith. Thanks for leaving the pages up. If you do remove them could you drop us an email please.
The problem with adding the underline (and when you review our notes you’ll see this was mentioned a couple of times) is that the line is a bit difficult to see. Adding a background color — just for focus/active — would do the trick.
As far as your struggle between using a lighter-colored text in the menu and the impact on design, I hear you completely. I struggle with the same and I’m often very close to minimum requirements. That was the case on my own blog and eventually darkened the text. You could address this by making the text larger though I didn’t check the numbers to see if it would then be sufficient.
Regarding handheld styles adding it to the head would be best as not all user agents that can work with HH styles in the first place will see the @media styles in the master style sheet. Offering it in the head makes it more likely it’ll be seen and used. That was the case for me. I usually test HH styles using the “Display CSS by media type” in the developers tool bar on Firefox but it didn’t work in this case. At first I though maybe there was no HH styling offered via another method beside user selection, but then I found them when I dug deeper and realized that must be the problem. Had they been in the head I could have selected them with my browser.
These topics and others are discussed in more detail in the notes. I will send them out in a few minutes.
Keith Bell responds:
Posted: February 11th, 2009 at 5:48 pm →
Thanks for the quick response, there, Mike — I’ve just received the notes, and will study them carefully.
Ben Gooden responds:
Posted: March 5th, 2009 at 11:03 am →
If the site is *so good* why is there HIDDEN text at the top of the page? By hidden, I mean non-visible text! “Keith W Bell European supplier quality specialist” is in black text on a black background at the very top of every single page throughout the site. That is search engine spam. I wouldn’t promote a site that was spamming. Why are you guys [accessites] giving cudos to a spammer?
The text in question only becomes visible when you disable stylesheet support. Yeah, Google’s going to love this site all the way into the spam bin.
Mike Cherim responds:
Posted: March 5th, 2009 at 12:20 pm →
Hi Ben. It’s not spam and Mr. Bell isn’t a spammer (that was kind of harsh of you to state that so bluntly). The text that is hidden by color is there for those who can’t read the image-based text. It’s redundant visually which is why it’s hidden. Make sense?
Ben Gooden responds:
Posted: March 5th, 2009 at 12:52 pm →
Hi Mike. Regardless of your opinions on the matter the search engines have a different view. If any text is hidden at ALL it is then considered search engine spam. I didn’t make the rules about what is considered SE spam and what isn’t. The SEs made those rules themselves. So before you’re ready to chastise me for rules I didn’t make how about you read the google webmaster guidelines regarding that. It’s pretty clear and straightforward.
If it’s there in place of an image, then why not add that to an image ALT attribute as it was designed for?
Mike Cherim responds:
Posted: March 5th, 2009 at 1:52 pm →
Ben, I didn’t chastise you, though I did remind you that it isn’t necessary to call the site’s maker a spammer when clearly he’s not. It is you that is running on opinion. This subject has been addressed and discussed many, many times amongst ourselves, with Google, at GAWDS, with the W3C, and through the WSG (and those are just the sources I know). It’s not spam. Our site has hidden text as well: main heading, jump links, etc. I do this on all sites I make, including a WCAG 2 AAA site (as recognized by the W3C WAI), and none of it is spam in Google’s or any SE’s eyes. If they get a report they investigate and see it’s in context and thus not spam.
To answer your question about why the alt attribute wasn’t used: it’s a background image and thus can’t support alt. If you turn off images, though, the hidden text becomes visible because that black background is actually an image itself. It’s all legit, not spam, and good for accessibility. We fully support our decision and back this site fully for the award level it earned. It’s not a spam site and Mr. Bell isn’t a spammer. If, however, you feel strongly about it I would suggest you report the site to your SE of choice and let them judge it for themselves. You’ll discover at that point that they won’t view it as spam — and that’s because it is not. This is not my opinion, it is fact.
Rule of thumb: Not all hidden text is bad or considered spam!
Joe Dolson responds:
Posted: March 5th, 2009 at 3:14 pm →
Hi, Ben - it’s not readily apparent to me that you’ve actually read Google’s guidelines for webmasters concerning hidden text. There’s a highly relevant quote on this question:
*Emphasis added.
The goal of any search engine is not to set up hard and fast technical rules and enforce them regardless of demonstrable intent - that would be suicidal. In this case, there is a clear intent to reproduce content which is on the page already in a manner which is available for non-visual users.
I’m not going to claim that this is necessarily the best choice of methods - it could certainly attract the attention of an automated reviewing bot from Google. However, on human inspection, I have little doubt that the site would be considered perfectly acceptable — and it’s the human perspective which is what we care about.
Mel Pedley responds:
Posted: March 5th, 2009 at 3:34 pm →
Images added via CSS (as opposed to within the page markup) cannot be provided with an alt attribute, so your response is something of a non-sequitur. The approach used to provide the alternative text when images are not available is perfectly legitimate and is no more spamming than this site’s approach to the same issue. Turn off images on this site and you’ll see what I mean.
Would Google regard this is spamming? Personally, I have a greater regard for the Google staff than you seem to have. I think they are perfectly capable of telling the difference between search engine spam and a desire to support a range of user groups and agents.
Phil Smears responds:
Posted: March 6th, 2009 at 2:12 am →
If his intention had been to spam he wouldn’t have stuck his own name in - like people are going to be searching for Keith Bells…yeah right.
Keith Bell responds:
Posted: March 9th, 2009 at 6:35 pm →
@Ben Gooden: Imperfect understanding of a topic often leads us to leap to wrong conclusions. If the points made by Mike, Joe, Mel and Phil have helped advance your knowledge (or that of anyone else who has followed these comments) in this crossover area of accessibility, CSS and the workings of search engines, then that is a positive outcome and I will choose not to be upset by your intemperate accusation.
@Accessites team: Thanks for saving me some work by your responses! I think you pretty much covered it, save to say that the site, complete with the so-called “hidden text”, has been live for over two and a half years and has not offended Google — it is regularly returned in the first page of search results for the most important keywords. Similarly for Yahoo, MSN, Ask…
David Zemens responds:
Posted: March 10th, 2009 at 9:27 am →
@Keith; I cannot added anything else that has not already been said by the Accessites team, Your comment about your page rankings, and lack of any punitive action by Google or others, shows imply that “The proof is in the pudding!”
Again, my compliments on a very nice website.
dani responds:
Posted: March 21st, 2009 at 8:42 am →
Inspiring high quality website, Keith, congratulations.
But, why Validome said it was n’t valid HTML 4.01 Strict?
Joe Dolson responds:
Posted: March 21st, 2009 at 2:14 pm →
Well, Dani - it does. At least, when I checked Keith’s home page, using Validome.org’s validator, it returned a confirmation that the page was valid HTML 4.01 Strict. Now, you may have checked another page — and it’s possible that you checked a page which the Accessites Team did not check which contains an error.
Regardless, without more information (specifically: the page checked,) your comment really doesn’t help anyone. Usually, people who are trying to maintain validity in their HTML appreciate help in maintaining the code — but only comments which contain specific information are really going to be useful!
Keith Bell responds:
Posted: March 22nd, 2009 at 11:25 am →
@dani: There are now a number of online validators, but they are not all perfect. Even the W3C validators have a few known bugs and can report invalidity where the code is, in fact, valid according to the specifications (though this relates more to the CSS validator than the HTML). I am not familiar with Validome, but perhaps it suffers from something like that.
I can assure you that all pages on the site are HTML 4.01 Strict and validate as such with the W3C HTML validator.
dani responds:
Posted: March 22nd, 2009 at 5:41 pm →
Oh no, sorry guys…
Keith’s site (kwbell dot biz) is perfect actually, semantically correct, and the submission notes is superb.
I was wrong, december14 dot biz checked, really sorry…
These are questions for kwbell dot biz (seriously):
1) Should we validate the mobile version against W3C-mobileOK or ready dot mobi?
2) On Keith’s homepage, the
h1called Introduction, thenh2is part of thetitle. What is the SEO effect?Mike Cherim responds:
Posted: March 22nd, 2009 at 8:27 pm →
I can’t answer number one aside from the mobile version should be the same as the screen version with only the style sheet being different. Perhaps I don’t understand what you mean.
As far as the SEO effect, I’d say little to none. A lot depends on a meta description, if provided, and title element, much more so than the main heading. The main heading just happens to be some of the first text on the page to get indexed, but a meta description with good title element use should prevail.
dani responds:
Posted: March 23rd, 2009 at 1:09 am →
Mike, which one is better? Mobile version which has the same features as screen version with the different style sheet or mobile version with less/selected features than the screen version? Thank you.
Mike Cherim responds:
Posted: March 23rd, 2009 at 7:36 am →
From the standpoint of practicality I’d say one version with two style sheets is going to be the smart money. From the standpoint of accessibility, serving different content by sniffing for devices will also have its flaws. Sometimes it won’t deliver the right content to the right person.
Keith Bell responds:
Posted: March 23rd, 2009 at 10:45 pm →
Hi again dani
“Validation” of the mobile version: First, there is no separate mobile version. The only difference between the standard and mobile display is the stylesheet. Second, you should note that ready.mobi and the W3C mobileOK Checker are NOT validators. They merely provide an indication of how “mobile friendly” a site might be, and frankly their results are often highly dubious and require careful interpretation. Sometimes the “problems” they report are just plain wrong, and sometimes they are irrelevant. For example, checking kwbell.biz on W3C mobileOK reports the “error” that “The document does not validate against XHTML Basic 1.1 or MP 1.2.” Well of course it doesn’t; it wasn’t written to that DOCTYPE. And in practice, it’s irrelevant because current mobile browsers are quite capable of rendering plain old semantic HTML. There’s not much consistency between these tools either: W3C mobileOK rates the home page at 91/100 (91%), while ready.mobi rates it 2/5 (40%). Further, ready.mobi says “It will probably display very poorly on a mobile phone”, which is simply nonsense, because in practice it displays just fine on an iPhone, a Nokia N95, a Nokia 6500 Slide, a Nokia 6500 Classic, and a BlackBerry Curve 8900, all of which use different mobile browsers!
SEO effect: I can’t add much to what Mike said, except to point out that the META description plays no part in ranking by the major search engines. Some of them use the data in the element to retrieve pages, and some to provide the description text underneath the link on the search engine results page, but it isn’t used for ranking. The TITLE element is generally the most significant, then the headings, link text and body text; and there isn’t a huge difference between an H1 and an H2.
Which is better: There is a lot of debate on this topic. People like Cameron Moll (warning: link is to an article written nearly 4 years ago) suggest that the context in which people access web sites while on the move is important and that as a result, dedicated, pared-down, context-aware mobile versions are better than simply providing an alternative display style. I think that in certain cases this is true, but it really depends on the nature and purpose of the site. For many sites, a different display style will be just as good as a separate mobile version, and this approach does not suffer from the disadvantage that a separate mobile version is essentially a second site, which needs to be maintained and kept “in sync” with the main site, and risks being neglected or forgotten like those crazy old text-only versions of sites that misguided developers used to build for “accessibility”. If you choose to build a dedicated mobile version, I think it’s better to put it on a separate subdomain (or if you insist, on the rather pointless .mobi domain) rather than trying to serve the mobile content by sniffing for mobile devices. As I have discovered in the last few weeks when experimenting with serving mobile style sheets by sniffing for mobile user agents, the mobile carriers often put themselves between the device and the web server and change the user agent string (probably a trick associated with transcoding) so the user agent string cannot be trusted. My own mobile service provider often replaces my phone’s user agent string with this truncated crap: Mozilla (compatible)/4.0 — which makes it look like a desktop browser!
Anyway, this is all very interesting, but I think it’s drifting away from Accessites’ core interests of accessibility, standards compliance, good looks and attention to detail. If you want to learn more about SEO and designing for mobile devices, there’s a lot of good information out there on the web. Those links, and a few minutes on Google, should get you started.
dani responds:
Posted: March 24th, 2009 at 9:40 pm →
Mike & Keith,
Time to start learning.
thank you for the corrections and suggestions. We should keep the main topic in this field.