New Accessibility Features in IE8

Hi, my name is JP Gonzalez-Castellan and I’m the Accessibility Program Manager for IE8. The IE team has been working towards making IE8 the most accessible browser possible, and we wanted to detail some of the work we’ve done toward this end. In this post I will provide you with some background on Accessibility, I’ll cover new UI features (Caret Browsing, Find on Page, Adaptive Zoom, High DPI, etc) and also platform features (support for ARIA, support for IAccessibleEx, and support for additional WinEvents) that improve the Accessibility of the browser.

Q: What percentage of users benefit when you make software accessible?

A: One hundred percent.

When you improve the Accessibility of software, or any product for that matter, you are also improving the Usability of the product. Usability is defined by the International Organization for Standards as the:

“extent to which a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfactionâ€

This is ultimately what we all want for the things we create. Accessibility ensures that a webpage is effective, efficient, and satisfying for user with disabilities. This allows for all users to reap the benefits. My favorite example to illustrate this is access ramps for wheelchairs. After the Americans with Disabilities Act was passed, public gathering places like airports added wheelchair ramps. Airports soon noticed that mothers with baby strollers and passengers with rolling suitcases were using the ramps too, since it was easier than picking up a stroller or a suitcase over the ledge. In much the same way, when you make software more accessible, everybody wins.

An example closer to the software realm is keyboard usage. Some users can’t use a mouse, and the keyboard is their sole input device. However, being able to perform common mouse tasks entirely with a keyboard not only benefits users who can’t use a mouse, but also users who can use a mouse but choose not to users may find keyboard shortcuts to be a much faster or more efficient way to interact with software.

New UI features that improve the experience for low mobility and low vision users

IE8 adds a number of new features that are particularly helpful to low mobility users - those users who prefer to use the keyboard, or devices that interact with the keyboard, over the mouse or other pointing devices. Features like the new Caret Browsing feature, Accelerators, Web Slices and revamped Find on Page help these users particularly, who also benefit when we reduce the number of steps to complete specific tasks. Low vision users will find the new Adaptive Zoom and High DPI support especially useful.

Caret Browsing

Caret Browsing is a new feature that allows users to navigate a webpage using a moveable cursor on the screen and the keyboard. Users can select and copy text down to a single character using only the keyboard. Other content types, like tables or images, can also be selected and copied.

Moving the cursor within the text of a webpage is similar to moving the cursor within the text of a Word document. Holding the shift key down and pressing the arrow keys selects text. Pressing F7 turns Caret Browsing on or off. It can be enabled on a per tab basis or for all tabs and windows.

Many users use the keyboard instead of the mouse because they find it to be faster for certain tasks. Users are now able to select a word, bring up Accelerators through the context menu key on their keyboards (which sits between the right Alt and right Ctrl keys), select Translate with Windows Live (or any other Accelerator), and see its meaning in Spanish without ever taking their hands off the keyboard.

Accelerators, Web Slices and Find on Page

You are probably already familiar with IE8’s Accelerators, Web Slices and the improved Find on Page feature. I’m not going to cover them again in detail, but it’s important to note how they each make the browser more accessible.

Accelerators simplify the common task of copying, navigating, and pasting into a single action. Keyboard only users can save a lot of time and keystrokes.

Web Slices bring your favorite pieces of the web with you. Web Slices are portions of a webpage that you can subscribe to and view updates directly from the Favorites Bar. This means that instead of having to open a new tab and having to navigate to the same page every so often to see if it has been updated, you can stick to your regular browsing until you get notified via your Favorites Bar that the page has been updated. This also saves a lot of time and keystrokes for blind users who can only use the keyboard.

With the revamped Find on Page feature you no longer get a dialog hovering over your page. Now you get the Find on Page toolbar below your tabs. As soon as you start typing in the Find textbox, IE starts highlighting the matches on the page with a yellow background and scrolls the page to your first match. This saves a lot of keystrokes since you do not have to click search to see if your term is on the page. IE also displays on the toolbar the number of matches found. The new yellow background highlighting makes it easier for low vision users to quickly find the term on the page while having a docked toolbar below the tabs takes up less screen real estate than a floating dialog. Screen real estate becomes more important when you start increasing the zoom factor of your monitor, which many low vision users do.

The key takeaway is that features that can be simplified for everyday tasks are beneficial for keyboard users, and as an added bonus, beneficial for the Accessibility community.

Adaptive Zoom and High DPI

The new support for Adaptive Zoom and High DPI has already been covered in depth on the IE blog and on MSDN, so I won’t go into too much detail here. Most low vision users benefit from an enlarged UI (user interface). In Windows Vista the Windows DPI Scaling feature only scales up the operating system’s fonts and UI elements (menus, toolbars, buttons, etc) but now it will also scale up IE8’s fonts and UI elements. When scaling IE8 we use UI elements that are drawn with more pixels, resulting in a higher fidelity experience. Sometimes the size of the menus and toolbars of the browser is big enough, but the displayed content on the webpage is too small. By using the Adaptive Zoom control webpages can look bigger. Compared to IE 7, in IE8 we do not just make all the content in the page bigger, but we actually redraw the page and adjust the content to avoid displaying horizontal scroll bars. This makes it easier to browse zoomed pages since you only need to scroll up and down, and not also left and right.

From the beginning the target audience for this feature was low vision users however this feature is also a great example of how making something more accessible also makes it more usable. I find myself using this feature all the time at home. I have my PC connected to my TV. I can normally sit 10 feet from the TV and enjoy all my shows without a problem. However when I try to use my TV as a PC monitor, I find that I can’t read much of the content when I’m 10 feet away. It is then that I use the Adaptive Zoom to make all the pages look bigger, so I can read them from my couch. Even though I might not be considered a low vision user, I find this feature extremely useful. In previous releases the horizontal scrollbar would show up all the time and I had to use my mouse to move the horizontal scroll bar left and right, besides the usual vertical scrolling. Now I’m able to do all my browsing just with vertical scrolling.

For more information, especially for developers who want to take advantage of High DPI in their webpages and WebOCs, please see: Making the Web Bigger

New Platform features that improve the experience for low vision and visually impaired users

In this section I’m going to cover the new support for ARIA (Accessible Rich Internet Applications), the IAccessibleEx interface, and the support for additional WinEvents for DHTML (Dynamic HTML) and how each of them affect the end-user experience.

Depending on the level of low vision some users require specialized 3rd party assistive technologies (ATs) to interact with computers, such as screen magnifiers while others can get along with features and tools shipped with the product and the operating system (Adaptive Zoom, High DPI support). Visually impaired users also use a type of AT called screen readers. A screen reader is a software assistive technology that ‘reads the screen out’ to the user. As we all know a webpage is more than a string of words and pictures. The way those words and pictures are laid out on the page, the way they interact with the controls around them, is not as easily read out loud as the text in a book. The HTML on a webpage is useful data for screen readers, but sometimes the HTML is not enough to programmatically convey to ATs all the information and interactions a webpage has. Here is where the new support for ARIA comes into place to markup the page with additional information, while, as we will see later, the IAccessibleEx implementation exposes this information to ATs. To complement it all ATs can now subscribe to 4 new WinEvents that get triggered by dynamic changing pages.

ARIA Support

The W3C (World Wide Web Consortium) defines ARIA as a syntax for making dynamic web content and custom UI (user interface) accessible. IE8 recognizes the ARIA role, state, and property information and exposes it to ATs, which in turn can use the Microsoft Active Accessibility (MSAA) and/or Microsoft UI Automation implementations to retrieve the information. Instead of building separate simplified Web pages for Accessibility, you can use ARIA to mark up your rich Web applications with roles, states and properties. For example, to match the behavior you created through a script, you can define a div element as a button, checkbox, or another ARIA role.

ARIA syntax is a great mechanism to use to unlock your dynamic, rich Web applications for everyone. Today Web pages with dynamic content and custom UI controls (such as TreeView controls) do the best they can to be accessible by reusing existing HTML controls. For example, custom TreeView controls are made accessible by defining each item as an HTML list element. This approach can add complexity to the code, make it more difficult to implement, and prevent all users from getting the same rich behavior. With ARIA you can markup your custom TreeView control with tree and treeitem ARIA roles.

From the early stages of IE8 we’ve worked closely with the W3C Web Accessibility Initiative group and Assistive Technology Vendors (ATVs). During the last year we were happy to hear that more browsers have pledged support for ARIA in their future releases while at the same time screen readers continue to expand their support for ARIA. Here you can find the list of ARIA roles, states and properties supported in IE8.

Support for IAccessibleEx

When IE8 recognizes ARIA information on elements, it exposes more information for these elements through the MSAA implementations, than HTML alone. However not all ARIA roles, states and properties can be mapped directly to MSAA’s Accessibility roles and properties. This is because ARIA definitions are different from MSAA definitions, and the ARIA scope is bigger than MSAA’s. The UI Automation Community Promise Specification will provide you with more background on the IAccessibleEx interface. This interface extends IE8’s MSAA implementation and allows richer information to be exposed and retrieved using Microsoft UI Automation properties and control patterns. This guarantees that all of the ARIA information can be made available to ATs (Assistive Technologies) through Accessibility APIs. Here you can find IE8’s mappings for ARIA to MSAA and to UI Automation.

ATs have supported the MSAA APIs for many years now, but they are starting to add support for UI Automation, including the IAccessibleEx interface. If an AT doesn’t support UI Automation, then it won’t be able to get some of the ARIA information from the Accessibility tree since the tree exposes through UI Automation what it can’t expose through MSAA. As a fallback, ATs are able to parse the DOM (Document Object Model) directly and extract the ARIA information themselves. This is a practice we are discouraging, since ATs constantly accessing the DOM causes performance and security issues. This tutorial will get you started with code samples to retrieve information from IE8’ Accessibility tree through UI Automation.

New supported WinEvents for DHTML

Due to the ever increasing dynamic nature of webpages, we’ve added support for new WinEvents to notify ATs when the content of a page changes dynamically. This way ATs can keep their users more in sync with the state of the page they are browsing. For example, a webmail client provides potential contact names when the user starts typing the first letters of an email address. As soon as those contact names are exposed we fire EVENT_OBJECT_REORDER so the AT becomes aware of the new options and can inform the user that those names are available for selection. The work item for ATs is to listen for these events and decide how they want to relay the information to their users.

The following are the 4 new events we want to encourage ATs to start listening for, with links to more information on what triggers each of these events:

[*]EVENT_OBJECT_REORDER[*]EVENT_OBJECT_STATECHANGE[*]EVENT_OBJECT_LOCATIONCHANGE[*]EVENT_OBJECT_VALUECHANGE

Conclusion

We’ve made key Accessibility investments both in the UI and the platform during the IE8 development cycle. If you are an end-user that doesn’t use ATs, you probably discovered a couple of new features that will come handy. You can now try those features you had heard about but didn’t know you could benefit from using them - like browsing the web from your couch using the Adaptive Zoom at 150%, or browsing in High Contrast mode to keep your eyes more relaxed, or using Caret Browsing to access Accelerators entirely through the keyboard. If you use ATs to browse the web, then we also encourage you to try IE8 out and share your experiences with us.

If you are a web developer we encourage you to mark up your pages with ARIA and let us know how it improves your web applications’ Accessibility. (Also let us know how the learning process went based on the documentation available on the internet.) Try out our new Adaptive Zoom on your web sites to further improve your site’s user experience with Zoom, try Saloni’s suggestions in the Adaptive Zoom blog post. If you are an assistive technology vendor let us know if the four new WinEvents worked the way you expected them to. Let us know if you were able to expose Accelerator and Web Slices to your users. Last but not least, let us know if you were able to get started with your support for UI Automation through the tutorial and the UI Automation Community Promise Specification previously provided.

JP Gonzalez-Castellan

Program Manager

More...

Edited March 17, 201410 yr by AWS