ODIN Blog

I'm delighted to be able to introduce Opera 10 today to Web developers and designers worldwide, and to take a moment to tell you the reason why I chose Opera not only as my employer, but why Opera 10 has become my own browser of choice.

Opera Software is a lucky company. We've grown up with the Web, we've been an integrated aspect of its evolution. And at the version 10 mark, we've gained strength – but more importantly, we're finding wisdom. We are confidently able to look at a longer-term vision of making our software truly the best experience on any device.

As a veteran of browser wars and Web standards arguments, it's very exciting for me to be working at Opera now. The company is at a stage where it is ready to take what has always been its innovative, strong technology, and commit to making it even better. Better for users like my Mom. Better for all devices, so I can integrate my personal information with ease. Better for designers and developers, so we can do our jobs with pride and work toward an open Web as it was meant to be: for everyone, everywhere, on any speed connection, on any device, using any browser or platform.

This means Opera 10 and the future of Opera's software initiatives are not only extremely important to the advancement of standards, developer tools and user experience, but to me personally, too. It's been difficult to feel as if our profession is stable and respected – it's a milestone in my own life to show that in fact, the work we do in this world makes a difference. For those of us building the Web, having a long-term commitment to excellence in a browser is also something worthy of professional acknowledgment.

Some of the developer-empowering highlights of Opera 10 include:

• Passing the Acid3 test with a 100/100 score and perfect rendering
• Adding additions and improvements from CSS 3 to our standards-support
• Implementing aspects of HTML 5
• Improving our developer tool, Opera Dragonfly, to assist developers in their workflow

I'm not the only one that's been having fun with Opera 10. Everyone on the Developer Relations team has gotten involved by working on showcases of new features and articles that will help you get the most out of Opera 10. Chris Mills' introduction to Opera 10, The Opera 10 Experience, offers an exhaustive list of browser features and the various snapshots we've put together.

Please, have as much fun with Opera 10 as we've been having! I recommend working with HSL colors and RGBA and HSLA transparency – that's been fun for me. The Selectors API has been implemented, so you code junkies will want to give that a run. Designers will be tickled to know they can use @font-face for embedded CSS 3 typography. Just one note of warning here: there's a little glitch in our implementation, so if you try to use professional font families with separate variants, you might run into trouble. That'll be fixed in a few weeks, and rolled out to you via our great new auto-update feature. And for those who can't wait, there is a future-proof workaround as well.

That's the other thing about Opera 10. This version is a major milestone for many reasons, but we'll have point upgrades coming out on a regular basis, meaning annoying problems like our font issue will get fixed automatically within a very short period of time.

Opera 10 marks a new time for our browser, with its sexy new UI, cherry-red restyled "O" logo, standards support including many advanced features not found elsewhere, and improved developer tools. Not only that, but to coin a silly Carpenter's song..."we've only just begun."

Download the browser, check out its features, and let us know what you think!

MAMA has been busy these last few weeks and we have some early results coming in. Based on feedback and requests here is a snapshot of what the Web's made of and some quick and dirty  analysis. The results are based on 4,225,113 URLs tested from over 250 countries; more about the methodology can be found in Dev Opera. It's worth noting that the numbers do not all add up as URLs may fulfill a number of the criteria. Therefore, percentages are guidelines only.

Headings

• No headings used: 2473197, 58.5%
• H1 used multiple times in a doc: 336523, 7.9%
• Headings don't start with H1: 681316, 16.1%
• Heading levels were skipped: 479294, 11.3%
• Heading levels were out of order: 298695, 7.1%

Structure on the web is fundamental for readable web pages by both search engines and assistive technologies such as screen readers and refreshable braille displays. With a heading structure missing on over half the pages tested, and implemented incorrectly on the majority of others these results are pretty disappointing - if not very surprising.

WebAim's screen reader survey findings for headings found that 52% of respondents relied on headings to navigate around pages. I think this is a woefully low number but is perhaps an understandable given less than half of the websites tested had any headings at all.

Constantly debated is the use - or rather misuse - of multiple H1s in a page, so much so there is even a website dedicated to the H1 debate. Should a page have just have one heading describing the unique page content or can it have two and include the website name as a second H1?

I'm not a fan of multiple H1s as it interrupts the logical page structure for screen reader users who rely on headings to get a mental overview of the page content and navigate it. Coding the website name as H1 also duplicates unnecessary information - a user can easily find out what site they are on by reading the page title, logo or other branded elements as well as copy.

The 11.3% of pages that skip heading levels may be evidence of headings are being used for presentation rather than structure. Often this is found in sites that fail to use good CSS and style text using H1-H6. This is especially confusing for a screen reader or refreshable braille display users as they get a partial and confused structure - a bit like a text book with half the index missing.

What MAMA shows is that we're far off from getting structure right yet. In the meantime we're snubbing search engines and assistive technologies, which get left out in the cold as they can't make sense of content. To get an idea of what I mean check out the Importance of HTML Headings for Accessibility video from Aaron Cannon.

Images

• title used in an img element: 647651, 15.3%
• alt used in an img element: 3176199, 75.1%
• title and alt used together in same img element: 575544, 13.6%

The thorny issue of images doesn't really contain many surprises with still a quarter of web pages lacking any alt attribute whatsoever. This of course doesn't take into account pages that have a mix of images both with and without alt attributes. What is interesting is that just over 13% use both title and alt around the same image.

There's rarely a good use case for this and has more of a negative impact of bloating your code and creating usability woes for screen reader and refreshable braille display users. In my experience, title text is very misunderstood and generally used incorrectly. Many page authors duplicate alt - or link - text leading to a classic case of too much accessibility as some screen reader users are forced to hear text twice.

Once we have had more time to analyse the data I hope to be able to let you know how many of the title and alt text combinations replicate text exactly in both.

Summary

• Table summary: 102821 times, 2.4%
• 1829 out of 102821 URLs using summary use "layout table", 1.7%

A summary on a data table is a useful way for a screen reader user to get information about the data in the table and how it is organised. Its intended use is not, however, to describe layout tables which should be avoided (and CSS used) and also should not be made evident to the screen reader user.

In the results we can see that 1.7% of URLS are using layout tables due to the misguided use of "Layout table" as the summary. This is really a conservative estimate as we can't predict every value to be tested however MAMA did unveil numerous instances of other misguided summary text such as: "layout", "layout table", "header", "navigation", "content", "banner", "main", "main table", "breadcrumb", "category"...the list goes on. Terms like this are of little use to the user when read out and bloat the amount of information they are forced to wade through.

This is a prime example of how there is a disconnect between the HTML 4.01 specification and WCAG 2.0 with actual usage. As HTML 4.01 states "This attribute offers advisory information about the element for which it is set. It should never contain primary information and should not duplicate information. WCAG 2.0 makes explicit reference warning against usage of the summary attribute on layout tables:

...if a layout table is used, then the summary attribute is not used or is null. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A summary would “break" this transparency by calling attention to the table. A null summary (summary="") on layout tables is acceptable.

Partly because of such bmisuse of the summary attribute on the web today the HTML 5 Working Group are advocating the removal of summary from HTML5. This is something that is not a popular with many accessibility advocates who argue that if used correctly on data tables to provide information about the table contents summary is beneficial. Fellow Opera Evangelist Bruce Lawson has some compelling ideas around summary in HTML5 as well as other accessibility implications for the new specification.

Coming next

We're only just starting to look at the data so if you have any further requests of what you want us to look at leave a comment. Full analysis and data will be published in due course together with breakdown by country. To get an idea of what we'll cover check out last year's MAMA results

.

Lasting nearly a month, from Rajasthan to Karnataka, Tamil Nadu to the Ghats of Varanasi, Shwetank and Bruce travelled spreading the message about Open Web Standards.

The students who attended were from various streams of study like mathematics, management, and even humanities (we even got a few professionals and some PhD students). However, most were graduate and undergraduate engineering students, particularly computer engineering.

The slides are made using Web Standards, and were shown using Projection Mode in Opera (just unzip, fire up index.html, then hit View>Full screen to see full screen slides).

• Bruce's slides: Web Standards for the Future (4.7 MB)
• Shwetank's slides: The Open Web, Mobile Web Trends, and the Opera Campus Crew Program (6.8 MB)

Shwetank has blogged some of the venues with lovely big pictures:

• BITS Pilani
• VJTI Mumbai
• NIT-Surathkal and PESIT Bangalore
• IIT-Madras and IIT Roorkee
• IT-BHU and NIT-Warangal