Hats Off To Opera

Well that didn't take long. It was just announced today that Opera's developers have received the first 100/100 test score on the new Acid 3 test. There is apparently a small rendering glitch they still need to take care of, but this is really incredible progress considering the test was just formally announced on March 3rd.

The Acid test, for those unaware, is a test page set up by the Web Standards Project (WASP) to allow browsers to test for compliance with various standards. The test runs 100 little mini-tests, and to score 100, you need to obviously pass all 100 of the tests. The first Acid test was set up in 1998 and checked for some basic CSS 1.0 compliance. Acid 2 came around in April of 2005 and tested for support for things like HTML, CSS2.x and transparent PNG support. The new Acid 3 test checks for support for CSS3 selectors and properties, DOM2 features and Scalable Vector Graphics (SVG) among other things.

It should come as no surprise that Opera was one of the first to successfully pass the test. After all, they were the second browser to pass the Acid 2 test (Safari was first). What's so impressive is the little amount of time necessary to complete the test. It took Safari about 6 months to pass the Acid 2 test, but it took Opera just under a month to pass the Acid 3 test.

Not that we can get too awfully excited about this. The two major players here (IE and Firefox) both have a ways to go. The last I saw Firefox 3 was up to a 71/100 score and IE 8 was at a frighteningly low 18/100. Let's just hope that IE can get the gap closed quicker than the 3 years or so that it took them to reach Acid 2 compliance! It's looking like Safari, who has their WebKit Nightly Build's up to 98/100, will be the next to hit a perfect score.

In spite of the needed improvements in Firefox and IE, this is great news and I think that congratulations need to go out to Opera's team of developers. They've done a great job of being proactive with their standards-support and it shows. I also think that WASP deserves a pat on the back for all of this....they are obviously doing a good job of pushing standards-compliance in browsers and giving vendors a goal to shoot for. We are starting to see some great improvements in compliance to standards across the web and I for one, am greatly looking forward to playing around with all the new toys!

Getting Started With ARIA

Finding purely static websites today is becoming harder and harder. The line between website and web application blurs more and more as clients want more interactivity and real-time interaction on their site. This rich experience raises accessibility concerns though.

To create a lot of these dynamic interfaces, we often have to use (X)HTML elements outside of their semantic meaning. For example, navigation is marked up using list-items. That is all fine and well for a sighted visitor...we can see that the list is meant to be navigation. However, to a non-sighted user who is relying on a screen reader to determine the usage of elements on a site, it is difficult at best to determine that the list is used as a navigation structure.

That is where Accessible Rich Internet Applications (ARIA) come into play. ARIA offers attributes that we can use to add semantic meaning to elements. One of those is the role attribute.

Add Some Information

Roles provide information on what an object in the page is and help to make markup semantic, usable, and accessible. Using our previous example of a list used for navigation, by providing the role attribute, we can help the user agent to understand that the list is being used for navigation.




• <ul role="navigation">...</ul>

Likewise, we can tell the user agent if a paragraph is being used as a button:




• <p role="button">...</p>

There are many different WAI roles to utilize. Nine of them where imported from the XHTML Role Attribute Module:

1. banner - typically an advertisement at the top of a page


2. contentinfo - information about the content in a page, for example, footnotes or copyright information


3. definition - the definition of a term


4. main - the main content of a page


5. navigation - a set of links suitable for using to navigate a site


6. note - adds support to main content


7. search - search section of a site, typically a form.


8. secondary - a unique section of site


9. seealso - contains content relevant to main content

The ARIA 1.0 specification also includes support for many more roles set down in the ARIA Role taxonomy. These include roles like button, checkbox, textbox and tree. There are many available there, so I am not going to try and show them all here For that you can take a look at the ARIA working draft.

Now For Some Meaning

In addition to the information provided by the role attribute, we can further add meaning about the state and relationship of elements with states and properties. Unlike roles, which are static, states and properties may change. For example, one state that is available is checked, which as you may guess is used with an element that has a role of checkbox. When a checkbox is unchecked the checked state is false. When the checkbox is checked, the checked state should change to true.

Using states and properties is rather easy to do:




1. <input type="text" name="email" aria-required="true"/>


2. <li aria-checked="true" tabindex="0" role="checkbox>>My Item</li>

As you can see, you just append the name of the state or property with an 'aria-a' prefix.

Add Some Style

In browsers that support attribute selectors in CSS, we can even use our new roles, states and properties to provide different visual effects to reflect an elements meaning. For example, we can target all items on a page that have an aria-required state with this:




• *[aria-required="true"] { background: yellow;}

In addition, some states have pseudo-classes that can be used to reflect the changes in state. Consider a list-item that is tagged with an aria-checked state. Using the :before pseudo-class, we can provide a different image with each state change. (Note: this example is used in the W3C Working Draft)




1. *[aria-checked=true]:before {content: url('checked.gif')}


2. *[aria-checked=false]:before {content: url('unchecked.gif')}

There is a lot of value in using ARIA. It helps to give meaning to the usage of an element on a page, greatly increasing the accessibility of a site. It's very easy to use, and doesn't break in browsers that don't support it. If you want to learn more about ARIA and how to start implementing it, I highly recommend checking out the W3C's overview on the topic.

Respecting What You Don't Understand

While at SXSW, I had the privilege of attending a panel called Respect! During the panel, Jason Santa Maria made a comment that really struck me. He said that it's "difficult to respect what I don't understand".

How very true. Respecting what we don't understand is if not impossible then extremely hard to do. Without some sort of knowledge of the process and steps involved in arriving at the solution, how can we really respect the work required to make the solution? I think this comes into play when working with both clients and co-workers.

As far as clients go, the solution involves making sure good communication takes place between you and the client. I think involving the client early and often helps to build respect and knowledge of what you do. If we meet with the client about a project, then hand them a design some time later, they are not going to have any idea of the process involved. To them, it's like delayed magic...they ask us to come up with a design, and viola, we come up with one.

However, if we go through a more involving process, they start to get a taste of all that goes into designing/developing the final product. We can start to show them our research, information architecture, wireframes and prototypes, all before actually showing them some sort of design. By walking through the project with them, a few things happen. First, they feel more involved. This can be great for clients...it's always difficult to just blindly trust someone else with such a crucial part of your company's marketing.

Secondly, by allowing the client to see a lot of these steps, they begin to gain a greater respect for what is involved. Let's face it, a lot of people simply don't realize how much goes into developing their site or application. The web is open to anyone, and it makes people feel like anyone can just jump in and throw together a website. That's why you run into clients whose site was developed by their mothers', brothers', lawnmowers', sons' cousin! By letting them see a bit more of our process, we help them to gain a bit more respect for what actually is going on in the professional development of a site or application.

Clearly, this can be taken too far. You don't want to involve the client too much. If you do, you may end up confusing the client, which leads to frustration. It's important to remember that while you want to get them involved, this is not their expertise, and anything you show them should be a very general perspective, and should be explained in non-technical terms.

I also said that respecting what we don't understand comes into play with co-workers. A co-worker with no knowledge of CSS is going to have a difficult time respecting your job of creating cross-browser compatible layouts. I think in this case we just need to try and remember just how involved our job can be, and should assume that so and so down the hall's job is just as involved.

I think there is an excellent argument to be made here for the "Jack-Of-All-Trades" worker. Having at least a basic understanding of a variety of topics will help you to respect the work of the people using those languages or techniques (not to mention, at least in my opinion, make you a more attractive candidate for employment).

In the end, it all comes down to communication. If we can find ways to effectively communicate to our clients and peers throughout our working process, we can hope to achieve some level of respect.

Quicker DOM Traversing with CSS Selectors

After looking at XPath and how it can be used to quickly traverse the document tree, I also thought I'd take a look at the W3C Selectors API as it kind of falls in that same line. At this point, it none of the major browsers support it. However, any WebKit build (Safari's engine) since February 7th supports it, and it looks like IE8 will be supporting it as well. I'd be eager to hear if anyone knows where Opera and Firefox stand on getting it going here in the future.

The Selectors API allows us to utilize CSS (1-3) selectors to collect nodes from the DOM. This is actually quite a common enhancement in a lot of Javascript libraries....CSS selectors are a very efficient and powerful way to quickly look up nodes, and since most people are familiar with CSS syntax, it is very user friendly. The Selectors API offers native browser support for CSS selectors using the querySelector and querySelectorAll methods.

The querySelector method as defined by the W3C returns the first element matching the selector, or if no matching element is found, it returns a null value.

The querySelectorAll method returns a StaticNodeList of all elements matching the selector, or if no matching elements were found, it returns a null value. For anyone familiar with DOM traversal, you are probably familiar with NodeLists. NodeLists are returned by methods like getElementsByTagName. The main difference between the StaticNodeList and a NodeList, is that if you remove an element from the document, a NodeList is also affected and therefore the indexes of the NodeList are altered. A StaticNodeList, however, is not affected...hence the Static part.

The querySelector and querySelector methods are very easily used:



1. //returns all elements with an error class


2. document.querySelectorAll(".error");


3. //returns the first paragraph with an error class


4. document.querySelector("p.error");


5. //returns every other row of a table with an id of data


6. document.querySelectorAll("#data:nth-child(even)";

In addition to calling the methods with a single selector, you can also pass groups of selectors seperated by commas, like so:



1. document.querySelectorAll(".error, .warning");


2. document.querySelector(".error, .warning");

The first line above would return all elements with a class or error or a class of warning. The second line would return the first element with a class of either error or warning.

You can see the advantage of having native support for the SelectorAPI by taking a look at some test results. SlickSpeed runs the test cases using the popular Javascript libraries Prototype, JQuery and ext as well as by using the Selectors API and the results are substantially quicker using the Selectors API. To run the native support test, you will need to go grab the WebKit nightly build. If you don't want to do that, Robert Biggs ran the test in various browsers and has the test results up.