IE7 Does Have Some New CSS Functionality

As I discussed in this post, I've been very disappointed with IE7's lack of enhanced support for CSS. However, IE7 does now support some CSS selectors that it didn't previously, so here is a brief summary of IE7's increased CSS support.

Adjacent Sibling Selector

The syntax for this selector is: E1 + E2 where E represents the HTML element being selected. This selector matches elements when E1 and E2 are both children of the same parent and E2 immediately follows E1 in the source code. (Note, the whitespace that I placed either side of the plus sign is optional, the code E1+E2 is equally valid).

For example, using the HTML code,

<div><p>Lorem Ipsum</p><blockquote>Ipsum Lorem</blockquote><blockquote> Integer molestie ligula</blockquote></div>

the CSS code

p + blockquote {text-indent: 1em; font-weight: bold;}

would cause the text "Ipsum Lorem" inside the blockquote tag to be indented by 1 em and displayed using bold text. However, the text "Integer molestie ligula" in the second blockquote would be shown with default blockquote formatting.

This selector is particularly useful when you want the formatting of the first element in a group of successive identical elements to be slightly different, such as the first item in a list, or the first paragraph in a group of successive paragraphs.

Child Selector

The child seletor is a refinement of the standard descendant selector that uses the syntax E1 E2, where E2 comes anywhere below E1 in the document tree (i.e. it's a child, grandchild, great-grandchild, etc.). The child selector limits this to only those elements that are children of the parent element, thus, grandchildren, etc. are not selected.

The syntax for the child selector is: E1 > E2 where E represents the HTML element being selected. This selector matches elements when E2 is a child of E1 in the source code (i.e. the document tree). (Note, the whitespace that I placed either side of the greater-then sign is optional, the code E1>E2 is equally valid).

For example, using the HTML code,

<div><b>Lorem Ipsum</b> <p><b>Ipsum Lorem</b></p></div> <p><b>Integer molestie ligula</b></p>

the CSS code

div > b {color: red;}

would cause the text "Lorem Ipsum" inside the first B tag to be displayed in red. However, the text in the second and third B tags would be displayed with default B tag formatting. The second B tag (containing the text "Ipsum Lorem") is a grandchild of the DIV tag, so does not match the selector. The third B tag (containing the text "Integer molestie ligula") is a child of a P tag and isn't even a descendant of a DIV tag, so again, it does not match the selector.

First-Child Pseudo Class

This extension of the child selector is also now functional in IE7 and allows formatting to be applied to only the first child of a parent element.

The syntax for the first-child pseudo class is: E:first-child E represents the HTML element being selected. This pseudo class can be used in combination with other selectors, for example, E1 > E2:first-child will match elements of type E2 that are children of elements of type E1, but only the very first child.

For example, using the HTML code,

<div><p>Text 1</p> <p>Text 2</p> </div>

the CSS code

div > p:first-child {background-color: green;}

would cause the first paragraph in the code to be displayed with a green background, whereas the second paragraph would have the default P tag background color.

Similarly, using the HTML code

<div><p><b>Text 1</b></p> <p><b>Text 2</b></p> </div>

the CSS code,

p:first-child b {color: red;}

would cause the text inside the first paragraph's B tag to be displayed in red, because it's parent P tag is the first child of the DIV tag. However, the text inside second paragraph's B tag would have default formatting because it is the second child of the DIV tag.

Conclusion

This isn't exactly a giant step forward for Internet Explorer with regard to CSS compliance, and there may be other new functionality that I am not yet aware of, but, I guess, at least it is a step in the right direction, albeit a tiny one.

Technorati Tags: ie7, internet explorer 7, internet explorer, css

BBC Reports Most Web Sites Don't Meet Accessibility Requirements

In a news story last month, the BBC reported that most web sites are "failing to provide the most basic accessibility standards for people with disabilities" with 97% failing to meet minimal accessibility requirements.

This report highlights the ever-increasing tension between building commercially successful sites and sites using the latest sexy technology and accessibility requirements. Given the surgent rise in "Web 2.0" sites, this tension and disparity can only increase.

The report quoted various figures highlighting the percentage of sites that failed in particular areas:

93% failed to provide adequate text descriptions for graphics

As discussed in a previous post, I think there is conflict here between what accessibility requirements demand and what is really and genuinely useful for users with accessibility needs . . . coupled with basic misunderstandings and confusion over how graphics should really be described, whether through the use of Alt attributes or other means.

73% relied on JavaScript for important functionality

Now, there really is no excuse here. Yes, by all means, use Javascript to provide a better user experience for those that can use it, but if your site cannot function without Javascript, you need to find a better solution.

78% used colours with poor contrast, causing issues for those with colour blindness

My main issue with this is, how many people are aware of what the various forms of color blindness demand in terms of color contrasts, etc. and whether it's even possible to allow for all of those needs while presenting a site that is visually pleasing for users with no such issues.

Having said that, there are several resources on the Web that give you the ability to simulate various forms of color blindness, such as the Accessibility Color Wheel and the Etre Colour Blindness Check.

In addition, one simple design principle will also help in this respect. Never use color alone to indicate something specific on your web pages. For example, if you have required fields on a form, don't just highlight them using a red background or red text, but use some other visual indicator that they are required, such as an asterisk or other mark.

98% did not follow industry web standards for the programming code

In my opinion, there was a time when it was virtually impossible to follow industry standards while having a web site that worked correctly in all major browsers. However, today it is certainly possible to adhere to W3C standards. Furthermore, the W3C code validator and CSS validator mean that you have no excuses!

97% did not allow people to alter or resize pages

I'm not sure exactly what this is referring to, but I assume the main issue here is preventing users from resizing the text. The key here is to ensure that you use relative rather than absolute font sizes and preventing users from changing font sizes is a big "No No" so make sure you're not doing it!

89% offered poor page navigation

Again, this point is a bit vague and I can't help wondering who determines what is "poor" and what criteria they used. Many web sites rely on Javascript functionality for page navigation, which, as discussed above, is definitely a problem.

When it comes to page navigation, the main things to remember are consistency and simplicity. It's also a very useful idea to have a good site map and to ensure that each page on your site is navigable to in just a few clicks.

87% used pop-ups causing problems for those using screen magnification software

Pop-ups are the bane of accessibility and usability advocates and should never be used without an extremely good reason. I think this issue is going to appear in a new form with Web 2.0 sites using AJAX functionality.

In conclusion, I think this stats are maybe a bit harsh and overstating the issues and there is always going to be some tension between accessibility advocates and those who want sites that appeal to bleeding edge users but there are still some basic principles that can, at least, minimize accessibility concerns that should be adhered to. Another issue to bear in mind is that, there may also be legal requirements that you need to meet and failure to do so could, in theory anyway, result in legal action against you.

Technorati Tags: accessibility

Alt-er Ego: Images and Alt Attributes

I was recently reading an article on Sitepoint.com about SEO mistakes and, in the comments to this article was an interesting discussion on the correct usage of the misnamed "alt tag." This inspired me to pen my own thoughts on the use of alt on accessible web sites.

Well, first things first, as another blogger points out, there is no such thing as an "alt tag", alt is an attribute of an img tag. As such, I shall (try to) refer to it as an attribute rather than a tag.

Before we can really discuss correct usage of the alt attribute, we need to discover what purpose this attribute is intended to serve. The W3 Web Content Accessibility Guidelines (WCAG) describe the purpose of the alt attribute as providing a "short text equivalent" of the image. The WCAG also states "[t] equivalents must be written so that they convey all essential content."

This is still a tad vague and elsewhere the alt attribute is described as being used to specify the purpose of the image or "to provide in textual form whatever information was provided by the image."

W3 also offers some guidelines on the correct usage of the alt attribute:

1. The alt attribute is required for all images, even if it is left as an empty string ("")
2. Users should not "specify irrelevant alternate text when including images intended to format a page" (which should be indicated by an empty string).
3. The alternate text must be meaningful.

It's also important to remember that correct HTML markup provides two other attributes that are often confused with the alt attribute, the longdesc and title attributes and the alt attribute should not be used instead of these.

Another incorrect usage of the alt attribute, which is seen on many web sites, is using it as a tooltip. The text in the alt attribute must never contain information that is additional to that conveyed by the image. In fact, browsers are not even "required" to display the alt text as a tooltip at all and some popular browsers, such as Firefox, do not do so.

Purpose of the Alt Attribute

Before I examine the correct usage of the alt attribute, it's also important to recognize that there is some disagreement as to its fundamental purpose.

As stated above, its purpose is to provide a text equivalent, but an equivalent for whom? Many people concentrate on this attribute solely as a means of providing information to visually handicapped users who cannot see the image being displayed. However, this attribute is not there just for those with visual handicaps but is also intended to be used for anyone whose web software does not display images. Thus, it is also for users of text-only browsers, screen readers, and so on.

Sometimes the accessibilty needs for visually handicapped users needs to be balanced against the needs of other users. However, in my personal opinion, in the real world, the vast majority of web sites are browsed by sighted users using standard web browsers and the only people that would gain any real benefit from well-formed alt attributes are visually handicapped users. In fact, alt attributes serve no purpose whatsoever for sighted users using standard web browsers (IE, Firefox, Safari, Opera, etc.) and they are not meant to!

Thus, my discussion of the correct usage of this attribute will have a definite bias towards straightforward accessibility for users with visual handicaps.

Correct Usage of the Alt Attribute

I'm going to start off with a bold and possibly controversial statement: in most cases, unless the image is both functional AND contains text within the image, the alt attribute may serve no purpose at all.

So, let's examine that statement in the light of a few scenarios.

Supposing you have a web page containing an image that is merely illustrative of the surrounding text. For example, a web page about yourself, containing a head and shoulders photo of yourself . . . or a page about San Francisco containing an image of the Golden Gate Bridge. In such instances, the images only really serve a purpose for sighted users. Does a blind user gain anything from knowing there's a picture of yourself, or the Golden Gate Bridge on the page? In my opinion, the answer to that question is a clear "No" - even if the user had, at one time, seen either yourself and/or the Bridge. What use does it serve the typical user with a visual handicap to have "picture of Golden Gate Bridge" or "Golden Gate Bridge" read out by their screen reader, or transformed into braille, or whatever? In fact, it may even interrupt the flow of text such that it actually causes confusion.?

On the other hand, what if your navigation bar uses images containing text such as "About Us," "Contact Us," etc. linking to the relevant pages. In this instance, unless those images contain alt text, fundamental functionality of your site will be lost to anyone that cannot, for whatever reason, see those images. So, here you clearly need to have alt attributes that describe the purpose of those images and that contain the same information as those images, as discussed above.

This is in clear contradistinction to the self-photo or Golden Gate Bridge examples. The head and shoulders photo really just serves the purpose of giving a sighted user a visual cue as to your appearance. The GGB shot, on the other hand, probably only serves the purpose of breaking up the monotony of the text on the page or to provide a more pleasing visual layout. Thus, in both cases the purpose is primarily visual and serves no other function.

Conclusion

1. You must have an alt attribute for all of your images, even if it's empty
2. Alt attributes must not contain information additional to that in the image itself
3. Alt attributes are really only useful if the image is both functional and textual

Technorati Tags:
alt tag, html, accessibility

Gotcha Captcha!

In a recent post on the Official Google Blog, the author describes how Google is implementing an audio alternative to the highly visual Captcha human-verfication methodology for users with visual handicaps.

Kudos to Google! As an advocate for accessible web sites, I applaud Google for introducing this and I urge any readers implementing Captcha on their own web sites to consider the usability ramifications of this method. Captcha, by its very essence, is a non-accessible method of verification so, if your site is using it, you may even be breaking the law, particularly if your site is in the U.S. where Rehabilitation Act and ADA (Americans with Disabilites Act) requirements are pretty stringent, and especially if you run a government web site or you sell directly to government bodies.

Although not web-related, a recent lawsuit in the U.S. has highlighted accessibility issues and gives an indication as to how serious this issue is becoming. In the case, American Council for the Blind v. Paulson, Sec'y of the Treasury, the court ruled that the Treasury's failure to provide the blind with "meaningful access" to paper money violates federal law.

The judge ruled that the "Treasury Department's failure to design, produce and issue paper currency that is readily distinguishable to blind and visually impaired" people violates federal law, since paper money effectively precludes them from "meaningful access to U.S. currency."

I have to admit, I'd spoken about this very issue before--after living in the U.S. for several years and realizing how difficult it is, even for a sighted person, to distinguish American bills. In the U.K., each denomination of paper money is made to be as distinguishable as possible from other denominations, by color and size. It surprised me that, in a country that places such an emphasis on accessibility that the country's own currency would be extremely inaccessible ... but, then again, the American people seem pretty resistant to change when it comes to money!

So, to get back to the world of web accessibility, how accessible is your site? Do you comply with Web Accesibility Initiative standards or legal accessibility requirements, such as the American Section 508 requirements, British requirements under the DDA (Disability Discrimination Act) or European accessibility initiatives? And if you've implemented Captcha, what alternatives do you provide, or are you blocking the visually handicapped from your site?

Technorati Tags: captcha, accessibility

Disappointed with IE7

I'm disappointed with IE7. I had read so much blurb about IE7 was supposed to be sacrificing backwards compatibility in order to be more standards compliant. Compliant schmompliant!

I'm an avid fan of Cascading Style Sheets (CSS) but, like many web developers, was disappointed by the number of CSS properties that IE6 did not support. Never mind, I thought, IE7 will support them, then we'll be fine. How wrong I was. So far, I haven't found a single CSS property that I was hoping IE7 would support that is actually supported. Maybe it now actually now does correctly the stuff it always supported, but incorrectly, but it doesn't seem to have added anything new ... at least, nothing that I was hoping for.

Two examples, fixed positioning and the IE disappearing text bug.

Fixed Positioning

The idea of fixed positioning is that it enables a page element to be displayed in the same position on the screen (or, more correctly, "viewport"). This gives a simple method, avoiding Javascript, of creating those "sliding menus" etc. that always stay in the same position on your screen even when you scroll up and down ... such as those found on the British Royal Family's web site, for example.

In CSS, to achieve this functionality, all you have to do is assign the style "position: fixed" and then assign the left (or right) and top (or bottom) properties. This works great in Firefox and Opera but doesn't work at all in IE6 and still doesn't work in IE7!! Why? Isn't this supposed to be Microsoft's standards compliant browser?

Disappearing Text Bug

This is a pretty well-known bug in IE where by text in an element close to a floating div, just disappears ... though you can see if if you select the area of the screen where the text should be, using your cursor. The simplest way to fix this bug is to assign the style position: relative to the offending elements. This bug is a great annoyance, particularly when you primarily check your code in a non-IE browser. Surely IE7 would fix such a serious bug, so serious that it actually causes page content to disappear?! Well, yet again, just the other day as I was checking a new web page in IE7, I noticed text vanishing before my very eyes, so, good ole position: relative to the rescue.

Let's hope IE8 does a better job ... I wonder how long we'll have to wait.

Technorati Tags: ie7, internet explorer 7, internet explorer