Video: Todd Kloots — Developing an Accessible Web 2.0 Widget Framework

Video published 2009-05-13.

• Download iPhone/iPod-compatible video file (320x240, .m4v)
• Slides

Transcript:

Todd Kloots: Hello, my name is Todd Kloots, and I work for Yahoo! — specifically, on Yahoo! User Interface Library. And today I'm here to talk about architecting an accessible Web 2.0 widget framework.

The YUI Library is currently in a state of transition — we're in the middle of building YUI 3. So the current version of YUI is YUI 2, and that's a library that really has evolved over time, and as a result, the widgets in the YUI 2 library don't share a common architecture. And while we do have some accessibility features across the library, not all widgets have accessibility taken into consideration from the very start. So we used YUI 3 as an opportunity to really take a fresh look at the library, develop both a common widget architecture, but also take accessibility into consideration from the very, very beginning, and build it into the foundation of our widget library.

One of the other interesting things about YUI 2 is, although it's evolved over time, this has resulted in somewhat of a consistent API, but this has also allowed some of our very best ideas to bubble to the top. And so we've been able to take those ideas with regard to accessibility, and migrate those over into YUI 3. So while we're in this transition, I think that this talk might more appropriately be labeled 'Lessons Learned While Architecting an Accessible Web 2.0 Widget Framework'.

The first lesson we've learned while working on accessibility in YUI 3 is that it's really important to build on existing best practices. And what I mean by that is that we don't want to exclusively rely on the latest technologies as the sole means of making a widget accessible. To paint a clearer picture of what that means — one of the very latest technologies with respect to accessibility is the ARIA specification, and that specification has been implemented in all the latest versions of the A-grade browsers. And while each of those latest versions of the browsers has support for ARIA, what we've found at Yahoo! is there's actually a significant number of our users — approximately about 60% — who are using browsers that actually don't have support for ARIA, namely IE6 and IE7.

And when you take that into consideration, and you also consider a recent study done by the Paciello Group regarding ARIA support, and all the latest versions of every browser, their findings indicate that while the latest versions of all the browsers have support for ARIA, the degree to which ARIA is supported in those browsers is very inconsistent.

And not only is support for ARIA inconsistent in each of the browsers, it's also actually inconsistent in each of the screen readers. So on the Code Talks Wiki, for example, for a given ARIA role or state, you can look up and see how that role is support in each of the major screen readers.

So when you take all of that into consideration, and you also consider a recent study done by WebAIM, concerning the preferences of users of screen readers, although most users of screen readers actually update to the latest version within the first year of its release, a significant percentage — about 25% — are actually still on older versions, versions that might be three years old. Which might mean versions of screen readers that actually don't have support for ARIA.

To sum up: many users have older browsers and older screen readers, so it's really important that when we're considering accessibility that we layer in our support for accessibility, as opposed to relying exclusively on the latest versions of technology, such as ARIA. For YUI 3, what this has meant is that we've really made Progressive Enhancement one of the guiding principles of our widget framework design to account for this. So that's the first lesson we've learned — building on best practices is critical.

I'd like to introduce the next lesson that we've learned while developing YUI 3 with a video excerpt from a talk that Douglas Crockford gave here at Yahoo! a couple of years ago. Douglas is, of course, the principle JavaScript architect at Yahoo!, and he gave a talk titled "The Theory of the DOM: An Inconvenient API". I'll play the excerpt of that talk for you now.

Douglas Crockford: When I started doing the classes in JavaScript, a lot of people came to me afterwards and said: we really liked the information about JavaScript, but you didn't say anything about the browser, and the browser is where we spend most of our time. So, could you do something about that? I thought about that for a long time, because what is the browser? The browser is a vast source incompatibility, pain, and misery.

Todd Kloots: So, "the browser is a vast source of incompatibility, pain, and misery" — and that's really what I'd like to title the second lesson.

To underscore that point, I'd like to reference a blog entry written by Eric Miraglia titled "672 Things". In this blog entry, Eric theorizes that for web developers, when you're developing an application or site for the Web, there are approximately 672 things that you have to take into consideration. He arrives at that number by saying: first, there are several different knowledge areas that an individual frontend engineer needs to be familiar with — for example, HTML. And each one of those knowledge areas is actually subject to four dimensions — there's the specification, there's the implementation of that specification in the browsers, that implementation inevitably always has defects, and so the community of developers ends up coming up with theory and practices for working around those defects. And of course, there isn't just one knowledge area, there are many: everything from the DOM, to CSS, to JavaScript, to the various data transport mechanisms in the browser. And there are, of course, multiple platforms to consider: from the Mac, to Linux, and each of those platforms has multiple browsers available for it.

So the numbers tally up such as this: seven different knowledge areas, four dimensions each, approximately three platforms, multiple browsers per platform, and then not to forget that every browser has two rendering modes, both a quirks mode and a standards mode. So that's how you arrive at this number, 672. And of course, this is without even considering accessibility as one of the knowledge areas — so when you add accessibility to this equation, you arrive at a number much greater than 672.

When you consider the accessibility knowledge area, and you just consider, for example, one slice of that, which would be ARIA, it of course is subject to the same four dimensions that Eric talks about in his article — the specification, the implementation, defects, theory and practice.

So to summarize: if DHTML development is difficult enough, accessible DHTML development is even more so.

I'd like to underscore that point with a quick example. When I set out to incorporate ARIA into the YUI Menu, of course I read this spec, and I had designed my menu with good semantic markup, and because it was a navigational menu, it was a set of unordered lists that were nested using anchor elements. And then after using the good semantic markup, and adding support for the keyboard via JavaScript, I then layered in support for the ARIA roles and states, started up Firefox, started up JAWS, one of the leading screen readers for Windows, and tested it out. This is a quick screencast of what that experience was like.

Screencast audio: Tab menubar home, http://www.connectsubmenu, http://developer.yahoo, menu connectmenu, developernetwork http://flickr, http://jumpcut, http://PIM submenu, http://Profiles http://Profileescape. Menubar.

Todd Kloots: So as you can see from the screencast, and hear from the audio portion of the screencast, although I had used really good semantic markup, the semantics of HTML were actually superseding the semantics that I had laid in via Progressive Enhancement, so the semantics of ARIA, rather, were being superseded by the semantics of HTML, which was not the experience I would have expected. So rather than screen reader actually telling me that each anchor element was a menu item, which was the role I had applied to each anchor, it was still announcing each anchor as what it was natively in HTML, an anchor element, by reading its HREF attribute.

So I decided to test this in another browser, with another screen reader. I started up IE8, and I started up Window-Eyes, and this was the result I got.

Screencast audio: Home. Connect pulldown. Developer Network. Flickr. Jumpcut. PIM pulldown. Profiles. Mobile. Menu Connect.

Todd Kloots: So what I found was that the user experience, depending on the screen reader you were using, was actually quite different. It seemed as though Window-Eyes actually got the implementation that was more in line with my expectation, which was that the semantics that I had applied via ARIA actually had superseded those of HTML.

So, my findings were that when you're designing for Progressive Enhancement with respect to accessibility, sometimes best practices can cause some collisions, which was the case in my menu. And the point of the two screencasts wasn't necessarily to point out deficiencies in Jaws, for example, and how Window-Eyes is being a superior screen reader, because they both have their strengths. And after all, because the ARIA spec is still evolving, bugs are to be expected with regard to implementations, and browsers, and screen readers. But what I found really frustrating as a developer was that it's really difficult, and sometimes impossible, to work around these deficiencies or bugs, because as a developer in the browser space, you actually are not able to detect any assistive technology running in the browsers.

So I found myself in this landscape where I was addressing familiar types of problems — incompatibilities and inconsistencies are very familiar to any frontend engineer — but unfortunately I had no good solutions at my disposal. Because again, I can't detect assistive technology, and therefore I can't make the user experience better for users of one assistive technology, or the other. And again, DHTML classically is a very mutable set of technologies, and frontend engineers are very used to being able to, for example, do some browser detection and either fix bugs in a given browser, or supplement functionality that's missing in one browser, but is available in another browser. In the accessibility space, we're unfortunately not able to do that, and so our hands are tied in a lot of situations.

Going back to the state of ARIA support, what I found is that support for ARIA is still evolving. The implementations are incomplete and inconsistent between browsers and screen readers. And a lot of that is because it's unclear how things are supposed to work, both to the developers who are writing code for the browser, as well as the developers who are actually designing the feature set in screen readers, because there just aren't enough practical examples on the Web using ARIA for them to really get a sense of what these technologies are supposed to do. This is made even more difficult by the fact that ARIA support is not documented well by browsers or screen reader manufacturers.

So a lot of third parties have actually taken it on themselves to do this documentation. As I said earlier, the Paciello Group has done a really great job of identifying the differences between ARIA support across browser, and the Code Talks Wiki has really good support for documentation regarding how ARIA support differs across various screen readers. So this is what we've got, but I really think that this is where we need to be, which is: if you take Operas documentation on their CSS support, for example, you got these really good compatibility tables which detail very explicitly what CSS properties they support. And we, as developers, really need this from both the browser manufacturers and the screen reader manufacturers, if we're to make really informed decisions about what degree of ARIA support we're going to build into our applications and widgets.

We also really need from AT vendors the ability to detect whether they're present. Typically, the argument for not needing to detect assistive technology is that you shouldn't be building in any functionality exclusively for accessibility, because any functionality that you add for accessibility actually benefits everyone, whether it's a disabled user or not. A perfect example of that would be adding keyboard support to a widget — that's something that's beneficial to any type of user.

But I think that the need for AT detection actually goes beyond that. As I noted earlier, there are enough inconsistencies and incompatibilities between ARIA implementations and browsers that if we as developers have the ability to detect AT, we could supplement missing functionality, or make better decisions on the fly as to whether or not to use it.

And we could also deliver AT-specific features in the interests of performance. We know on the Web that every byte counts, and so if we know, for example, that the user is using a screen reader, we could leverage certain parts of the ARIA specification that are very specifically beneficial to users with screen readers, like for example, Live Regions, where you're able to actually speak text back to the user. That type of functionality might not necessarily be beneficial for all users, it might be actually beneficial for a very specific type.

So the other use case for AT detection is the ability to target specific types of users, and deliver functionality that is beneficial only to them. If you consider ARIA live regions as an example of that, where this is a piece of the ARIA spec that is designed specifically to allow developers to speak text back to the user. This might only be beneficial, for example, for users with screen readers — so it would be valuable in the interest of performance to only send those bytes over the wire if that is the type of user who is actually interacting with this application.

To sum up: support for accessibility adds significantly to the number of things that an individual frontend engineer needs to think about. Bugs exist, for example in the ARIA specification, and workarounds are sometimes necessary, but difficult or impossible to do. Developers who are interested in accessibility really need better documentation from both the browsers and the assistive technology companies. And I think that developers really need the ability to detect assistive technology, via JavaScript.

And one of the things that I think is the mission of YUI 3 is, our mission has always been to help reduce the number of things that developers have to think about. So in the accessibility space, this holds true of course, even more so. So our aim is to try to build as much into widget infrastructure and our utilities as we can, so that developers can focus on the bigger picture. So that is the second lesson we've learned.

The third lesson we've learned is that testing is critical, but it's also really, really difficult when it comes to accessibility. Testing, of course, is critical here at Yahoo!, because users are our customers, and so we need to take accessibility really seriously. But it's also necessary to clearly define what support means. So far, we've addressed support, for example in the browser space, via our Graded Browser Support strategy. Graded Browser Support has allowed us to not only identify those browsers that represent, statistically, the most likely visitors to Yahoo!, but those browsers that if we test against them are probably covering most of the meaningful browsers on the Web.

And if we try to extend the Graded Browser Support model to screen readers, it actually becomes quite difficult really quickly, because not every version of every screen reader supports every browser. For example, JAWS is limiting their support to Firefox and Internet Explorer, as has Window-Eyes. VoiceOver, on the Mac, support Safari, obviously, and I believe has support for Opera. And then on Orca, for Linux, you have support for Firefox.

And this is really complicated, also, because like I said earlier, not every version of every screen reader has support for ARIA, not every web browser has support for ARIA, as an example. So the testing challenges become: which browsers are you going to test when you're considering accessibility, and which browser versions? Along with: which screen readers, and which screen reader versions? So coming up with these combinations could result in a very large testing matrix, which would make it really difficult to test against.

The other question is how we are actually going to define support for accessibility. When we say it's accessible, does that mean it's accessible only via the use of ARIA? Or are we going to be testing our support for ARIA as well as the fallbacks that we've put in place using existing best practices for accessibility, as those other accessible hacks? And are we going to be testing in both modes of the screen reader? We're going to be testing in the screen reader with the virtual buffer, and on and off?

The other question, of course, that comes to mind with respect to testing, is: are we going to be doing manual testing, unit testing, and automated testing? What is really the most practical for us? We know for sure that manual testing provides the most insights with respect to accessibility, but we also know that unit testing and automated testing are also necessary.

And of course, testing is ultimately important because we don't want to be in the business of supporting browsers, and we don't want to be in the business of supporting assistive technology, we want to be in the business of supporting users.

To sum up on this point: testing is critical. It's more time consuming than just standard browser support, because of the complicated matrix of browsers and screen readers, as an example. There are tremendous number of insights that can be gained from manual testing, and that's absolutely necessary.

And because the matrix of support is difficult, it also makes filing bugs really difficult — again, because we don't have good documentation regarding the level of ARIA support in screen readers or browsers, when we do as developers find a bug in our ARIA support, we don't necessarily know who to file that bug with. So as a really conscientious developer, you'll probably end up filing a bug in multiple places, but that's, again, time consuming. So the more information we as developers have, the more we can contribute back to both browsers and the assistive technology vendors in a more efficient manner, regarding how to fix bugs.

How this impacts YUI 3 is that we're working really hard to figure out how we can define A-grade support for browsers and screen reader combinations, and this is something that we haven't really settled on the answer for, but we know is something that we need to figure out, and we're working actively towards. We also need to find a really practical way to ensure support for accessibility, because ultimately, of course, the goal is to train our users — all of our users — to expect more, not less, of the Web.

The fourth lesson that we've learned while developing an accessible widget framework is that new skills are required that a lot of developers actually don't already have. The ARIA specification, for example, provides a lot of guidance with regard to the development of accessible widgets, as does the corresponding ARIA best practices document. And as a developer, if you follow that guidance to the letter, you'll come up with a widget that probably works, but it won't necessarily be usable, and that's a pretty big distinction. There's a big difference between it working, and being usable, and to go from it working to being usable, how do we get there? How do we improve the usability of our widgets with respect to accessibility?

Well, the first thing we need to do as developers is to learn new skills. For me, that meant actually learning how to use a screen reader. As a developer who's interested in helping other developers, also learn how to use assistive technology, I'd like to point you to at least two resources to start. One — and this is a little self-promotional — is my own YUI blog entry on configuring your machine for testing with a screen reader. And the other is a blog entry that we recently offered by Marco Zehe, on how to test for accessibility using the NVDA screen reader, which is a free screen reader, open source, and the Firefox web browser. I think both of these are really good resources for developers who are looking to learn about assistive technology, to learn how to make their widgets more usable.

And the second thing, of course, we can do as developers, is to actually do user testing. And what I've found is that that feedback loop between developers and the users that you're targeting with respect to accessibility, is really, really important. Because there are insights you can gain into how something works, when you're actually with someone who uses assistive technology, that you could have never learned on your own. And that's simply because these are people that use this technology every single day, and they're going to have insights that you would never have. And so that user testing is really, really valuable.

To sum up: reading documentation and following directions only gets you so far. It's really when you take that next step, and you learn how to use AT, and you do user testing, that you really gain the valuable insights that take you from something working to something being usable.

For YUI 3, this was another thing that we really feel is our mission, is that this developer education both internally and externally is really important. We also realize that not every developer has the resources that we at Yahoo! have with regard to testing, so that's one of the values that YUI 3 can bring to developers, is that we can do a lot of usability testing on our widgets internally, and provide that value back to anyone who is consuming our widgets.

The next lesson we've learned is that living up to the desktop is really difficult. Before the ARIA specification came to be supported in each of the major web browsers, most users of screen readers actually interacted with a web page, or web application, via this concept of the virtual buffer. What the virtual buffer essentially does is it acts as sort of a proxy between the user and the Web page, or web application. And what is does is essentially takes a snapshot of that webpage in time, and maps a set of keyboard shortcuts to it that the user can use to interact with the page. As an example of that, you could press, for example, the "H" key to quickly navigate between all the headings on a page, the "L" key to quickly navigate between all the lists on a page. And while the interaction model provided by screen readers can be considered perhaps rather limiting in this respect, the real advantage that this has is it's very, very consistent from one web page, or web application, to another. Because again, the user isn't interacting with the page directly, they're interacting with a snapshot of the page in time, as provided by the virtual buffer, and all the keyboard shortcuts provided by, again, the screen reader, not by the page, because the virtual buffer essentially intercepts all events on the page, and is providing all the keyboard shortcuts to the user directly.

ARIA changes this interaction model, because it requires the virtual buffer be toggled off in order for the user to interact with the page. So when you implement a widget that has a port for ARIA, you as a developer, it's your responsibility to actually add support for all the keyboard interaction. With the virtual buffer off, the user is actually interacting with the page directly. And although this provides a huge opportunity for more rich interaction from the user standpoint, it also puts a tremendous amount of responsibility on the developer to get it right. So that responsibility that was previously centralized to a limited set of screen reader manufacturers, for example, has now been decentralized to a lot of different developers, who all might have various levels of experience writing accessible widgets. The challenge is, there's a tremendous number of little details when it comes to accessibility to get right, and again, we want to train the user to expect more, not less, from the Web. So the onus of responsibility, really, is now on the developers, and that's why it's so important for developers to learn how to use assistive technology when they're creating widgets.

Again, ARIA puts more responsibility on developers. There's lots of little details to get right, so it's really important to read the ARIA specification, to study to desktop interaction model, for example, to do user testing, to learn how to use assistive technology. Because again, we only have so many chances to get this right — we want to train users to expect more from the Web, not less.

And again, this is where we consider YUI 3 is really having an opportunity to get this right. If we can offload some of that responsibility from all the developers out there — all the millions of developers out in the world — and because we have the resources to do testing, to build and support for keyboard, for example, to build widgets out of the box, we can add value to developers by helping shoulder that responsibility, not necessarily putting all the responsibility on so many people to get it right.

The sixth lesson we've learned is: the Web is not the desktop. I'd like to begin this segment with another video clip by Douglas Crockford, and this is from the same talk.

Douglas Crockford: There is something really amazing about the Web; that despite all its deep problems, it's actually been a very, very effective interactive communications medium.

Todd Kloots: So, although the Web wasn't necessarily designed as an application delivery platform, it's been really successful at that. And that success has actually brought new challenges. The web obviously has abilities, and has succeeded where the desktop hasn't, in regard to the write once, run anywhere model. But it also has a lot of constraints, such as performance security, and accessibility.

When you consider, for example, ARIA. ARIA allows you to enhance the semantics of a widget so that users no longer see elements as native HTML elements, but as the widgets that you're actually describing them to be. So, for example, it allows you to transform an unordered list into a menu, so that users of screen readers hear menu item and menu rolls as they're navigating through the menu, as opposed to hearing it as a list.

It's perfectly reasonable to expect that when you use the ARIA roles and states to markup a widget, that the user is going to expect that the widget running in that browser is going to behave exactly like it does on that native platform. So a tabview that they encounter on Firefox, running on GNOME, is going to perform exactly like it would on that native desktop. But of course the challenge here is that we, as web developers, provide these applications that run cross browser, cross platform, so we can't guarantee that experience is going to be actually identical for each user of each different desktop environment.

So when you're developing your widgets, what you really need to consider is not necessarily what desktop am I going to mimic, but what is really best for the Web? And this was the case, for example, when we sat down to develop our ARIA plugin for our tabview widget. When we were developing that, the first thing that we took into consideration was, do we want to mimic Mac or Windows? And they're two very different interaction models for tabview. On Windows, when the tab list has focus, pressing the arrow key immediately loads the panel for that tab, whereas on the Mac, when you focused on an individual tab in a tab list, it isn't until you actually click on that tab that the tab content gets loaded. And as it turns out, the Mac's model for the keyboard interaction actually works a lot better for the Web, when you consider that a tabview's content might be loaded asynchronously, and you don't necessarily want to be firing off a lot of different requests for content just because the user is arrowing through the tab list to figure out which tab they want to load.

So the lesson learned was to not necessarily mimic a given desktop, but try to find those patterns on an individual widget basis, that actually work best for that widget, and work best for that widget in the context of the Web, not the desktop.

Here's a quick example — a quick screencast, of what the YUI tabview sounds like when it's using the ARIA roles and states.

Screencast audio: Tab control. Press the spacebar or enter key to load the content of each tab. Opera tab selected; one of four. Firefox tab selected; two of four. Explorer tab selected; three of four. Please wait, content loading for Explorer property page. Content loaded for Explorer property page. Explorer property page list: Microsoft Becomes Official, apache [xx]. Recent Original Stories, link page. Slingpage Announces Full Support for Firefox, link page.

Todd Kloots: The other thing to take into consideration is that because the content of every tab could be loaded asynchronously, we needed to notify users of screen readers that that content was in the process of being loaded, and for that we used the ARIA Live Regions. So that's another challenge that is different from developing on the desktop, which is that because so much might be loaded on the fly, you need to alert the user to the fact that this content is loading asynchronously, and let them know when it's OK to proceed with actually interacting with a given portion of a widget's functionality. The interaction model for Web-based widgets has a lot of nuances that are important to take into consideration, so it's important to not exactly consider the desktop as a Holy Grail when developing widgets.

The other challenge that ARIA presents with respect to browser development is that there's a lot of examples of things on the Web that are not wholly documents, or wholly applications. Take, for example, the Yahoo! homepage. The Yahoo! homepage is littered with tons of different widgets, tabviews, autocompletes, and for example, little applications for being able to read your mail, or sign into Yahoo! Messenger. So how do you classify this page? It's somewhat a document, from the standpoint that it's got a lot of straight-up content, but it also has a lot of application-like functionality.

So how to present this concept to a user of a screen reader is really challenging, because again, when you consider the standard way in which users of screen readers are used to interacting with the page through this concept of the virtual buffer, where they have a set of keyboard shortcuts that are mapped to different pieces of content, and again with the virtual buffer on, the ARIA roles and states don't work. So if they come to the Yahoo! homepage, there would be a certain advantage to them being able to navigate this document through those keyboard shortcuts provided by the virtual buffer. But in order to use ARIA, what we really need to do is encourage these users to toggle the virtual buffer off, which means they're going to find themselves in this space where they're in the scope of a document for which the virtual buffer would actually be useful, but they also need the virtual buffer off in order to interact with the widgets on that page. So a lot of this is going to require some user education, from the standpoint of learning how to use, and what to expect, with regard to this hybrid model. Because this model of development is so pervasive across the Web, from the Yahoo! homepage to Facebook, for example.

The other challenge that ARIA presents is this notion of what is the right role, what are the right semantics to provide, for given widgets? The web is full of examples of widgets that aren't really common on the desktop, for example an accordion view, and there is no corresponding ARIA role for an accordion. So you find yourself in this familiar circumstances of trying to find what is the best semantics, but which aren't the100% most accurate semantics. So, depending on the use case, or depending on how your accordion view has been structured, for example, it might more accurately be described as an ARIA treeview, or perhaps an ARIA tabview. These are the kinds of decisions that developers are currently faced with, considering the current state of the ARIA spec.

To sum up, it seems like the specs, in some ways, are always behind what is happening on the Web. Again, there are a lot of widgets on the Web that don't exist on the desktop, and so there's no ARIA support for those, and so developers have to make their best decision with regard to ARIA usage, with respect to those types of widgets. I think that from the standpoint of following design patterns, it's best to really borrow from the desktop as regarding your interaction model, as opposed to completely trying to mimic the desktop when you're doing widget development. Because again, the desktop really isn't the Holy Grail. The web has got a ubiquity to it that the desktop has never been able to achieve — and not only that, for many users, especially younger users, their first experience of a lot of applications is actually going to be Web applications, not desktop applications. So we really need to embrace how the Web is different, and create solutions that are unique and right for the Web, rather than trying to chase the desktop.

The other challenge that the browser has that the desktop doesn't necessarily have, is this challenge of performance. And this impacts accessibility because obviously the more code on a page you have, the more you're going to slow down initial load time, and render time, in the browser. But of course the challenge is that accessibility features like ARIA support require more code — for example, keyboard support, and management of the ARIA roles and states. So the challenge becomes how to be both feature-rich and fast at the same time

One solution for how to be both fast and feature-rich at the same time was proposed by Joseph Smarr, who was the Chief Platform Architect at Plaxo, and he came to Yahoo! several years ago, and gave a talk on performance. And one of the insights he offered was to be lazy, because nothing is faster than doing nothing.

Joseph Smarr: And the thing about laziness, the reason why it's so important for all kinds of optimization work, is that if you can get away with not doing something now, worst case you'll have to do it later, but you may not have to ever do it at all.

Todd Kloots: So how does this concept of laziness play out using the example of a Web application? Well, here's a screenshot of Yahoo! Mail. As you can see, there's tons of various small widgets on this page, tons of interaction points that the user actually might interact with. But the thing is, if we were to actually front load this widget with all this functionality to start, you would have significant challenges with respect to making this application perform. So what we really need to do is consider is how we can be as lazy as possible with functionality that is delivering accessibility specific features. So that, for example, we might not load the ARIA keyboard support for toolbar until that toolbar receives initial focus.

So this goal of being able to support laziness as a road to furthering accessibility is really at the heart of our development of YUI 3, because we're trying to develop a much more modular widget architecture, so that we can have some core functionality that the widget can have on the page to start, and then we can layer in functionality on the fly, such as keyboard support, or ARIA support, as needed. That way we can speed up initial page load, speed up initial render time, without having to make sacrifices necessarily, for accessibility.

This concept of a modular widget architecture, just to sum up, not only helps us be lazier in the interests of improving performance, but it also gives our developers the flexibility of enhancing widgets with functionality on the fly, as well as encouraging innovation. There's lots of research going into how to both find the right interaction model for our widgets, as well as how we can create our widget infrastructure to both balance performance with accessibility.

The seventh lesson we've learned while developing YUI 3 is that widget frameworks can't do it all. The Web is full of examples of widgets that aren't necessarily directly mapped to specific things on the desktop. And if you take, for example, this screenshot of the navigation from Yahoo!'s OMG site, which is our celebrity gossip site, the primary navigation for this is somewhat a tabview, a menubar, and splitbuttons all in one. So the challenge becomes, if you want to enhance the semantics of this UI control through ARIA is: which thing do you choose?

The other challenge is, from a widget development standpoint, is this a widget that we want to offer from YUI 3 right out of the box? Probably not. And because there's always going to be needs for new styles of widget development, because developers like coming up with new things, visual designers like being creative — there's always going to be a need to write something new. So our widget framework cannot do it all.

The other reason of course, is not just out of necessity, but out of geek pride. Engineers like taking a fresh look at a widget, and rebuilding it from scratch. There's always this notion of: I can do it better, I can do it lighter, I can do it faster, I can do it with a better feature set. So we really want to encourage this style of development, not necessarily suppress this style of development.

So there's lots of good reasons for custom widget development, and we want to try to be able to foster that with YUI 3. We know that our widget framework will not have everything, and we know that there's no definitive solutions, there's no definitive most accessible tabview. The needs will continue to emerge as will the solutions for those needs, so custom widget development will always be valuable, and will always be necessary.

For YUI 3, what we want to do is really not only provide an accessible widget framework, but to be able to foster designing accessible widgets by building a set of utilities that are also very focused on accessibility, so that we can make custom widget development easier. We also want to provide this modular widget architecture, because we think that that'll be valuable, because a lot of times making a widget more accessible doesn't necessarily mean a re-write of the widget from the ground up, it means actually supplementing that widget with new functionality. And that's where our class extension and plugin model really becomes valuable, because perhaps making a more accessible tabview just requires the creation of a tabview plugin that adds even more keyboard support. Or new navigational patterns for navigating the widget. So again, it doesn't necessarily require re-writing the widget, but maybe just supplementing the widget with new functionality to make it even more accessible. So both models of custom widget development are completely valid, and we want to be able to support both, going forward with YUI 3.

The final lesson we've learned, lesson eight, is evangelizing best practices is really critical. No matter how great a job we do at making really, really accessible YUI 3 widget infrastructure, as well as providing core utilities, what we need to let users know is that using YUI on your page alone does not make your site accessible, because there are so many other things that need to be taken into consideration from the big picture. So evangelizing best practices for accessibility, as they range outside the widget scope, is really important. That's one of the things we try to do at Yahoo!, is evangelize best practices for accessibility, and we try to do that also outside of the company as well.

And this is really important, because people find unintended uses for products all the time, and that's highlighted by this slide, where someone has used post-it notes as a means of decorating a lamp. As engineers, you could build the most accessible DHTML menu, for example, but because DHTML is so mutable, someone is easily able to take that and either make something that's even more accessible, or actually hamper its accessibility in some way. Developers are no exception to this rule of products being used for unintended purposes, so the more we educate developers about really good design patterns for accessibility, the more we can help encourage developers to do something that's really great for accessibility, as opposed to something that actually works against a widget's accessibility.

Again, developer evangelism and education is something that we really take seriously here at Yahoo!, and we try to do a lot in the community as well. Because there are many really great frontend engineers that just don't have much experience with accessibility, and there are many new developers who are just trying to get the basics down. So we need to teach developers at all different levels, and we need to teach developers the complete story of accessibility, and how it fits together, just beyond the scope of a given widget.

To further help that cause, we have an accessibility category of YUI blog, we teach classes, we're going to be drafting a set of widget development guidelines that'll be part of the YUI 3 site. We're also going to have as many accessibility focused examples of our widgets as possible, in our YUI 3 examples gallery. We also try to contribute those examples back to other places on the Web such as CodeTalks.org, where we know that people go to look for examples of how to build accessible widgets.

To sum up: DHTML widgets are always very mutable, and so it makes it very easy to implement both good and bad user interfaces. So developer education is really the key to helping developers do things that are more accessible, as opposed to less accessible.

So I'd really like to try to incentivize anyone out there who really knows a lot about accessibility to contribute to a project, if you're not already doing so, or start a new one. To blog about solutions that you've found that are great for accessibility, to contribute back to the community in that way. There's also tons of opportunities that you can contribute to through CodeTalks.org — you can submit test cases, examples, and other findings that you've come across with respect to accessibility. And the other way you can really get involved as a developer who's really interested in accessibility, is actually to file bugs with the browser manufacturers, and the AT vendors. That's a tremendous way to make things better for everyone — both developers and users.

So this is the complete set of lessons learned. It's really important to build on existing best practices. Don't forget the browser is a vast source of incompatibility, pain, and misery. When it comes to accessibility, that new skills are going to be required, that you don't already have. That living up to the desktop is a difficult challenge, but don't forget that the Web is not the desktop, and so don't forget to really take into consideration what's right for the Web when you're developing your widgets. We also remember, of course, that our widget framework won't be able to do it all, and so it's really important to foster, as much as we can, new widget development, through the set of accessibility, minded utilities in YUI 3, as well as the ability to extend our widgets in YUI 3 with enhancements suited to accessible functionality. And lastly, to evangelize best practices.

So we realize the burden on developers, and for YUI 3 we're really trying to help shoulder that burden as much as we can, with respect to accessibility. Because we know that we, as YUI, can help developers, because we have time and resources with respect to accessibility that a lot of developers out in the field just don't have. For example, access to a lab for doing testing with various assistive technology, or access to users who are disabled that we can test with. So we can do user testing, and testing with assistive technology — things that not all users have access to. We also have the ability to help users directly, as members of the YUI team, because we have the advantage of scale. Any accessibility enhancements that we make to YUI that make it back into Yahoo!, benefit users across the Web, on a tremendous scale.

So in short, we know the opportunity to get this right is huge, and we know that getting there will not necessarily be easy, because of all the challenges that I've talked about in this talk. But we also recognize that there will always be new challenges and solutions, and that those solutions are likely to come outside of Yahoo!, and so we want to provide, as I said earlier, a means of empowering developers through the use of the widget framework. Again, through utilities that make custom widget development easier. So we want to really foster that concept of a thousand flowers blooming.

That concludes the talk. Again, my name is Todd Kloots, my email is kloots [at] yahoo [dash] inc.com, and you can also follow me on Twitter; my handle is toddkloots.

Thank you for coming.