You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
This is Tim McConnell, Program Manager on the SharePoint Foundation team. For the 2010 release, I’ve worked with SharePoint platform and partner teams to deliver powerful, reliable, accessible user experiences. Like Office, Office Web Applications, Windows, and teams across Microsoft, everyone in SharePoint strives to remove barriers that make software difficult to use. Sometimes improvements can be obvious, like the reorganized Ribbon user interface. However, some users may not notice changes that can transform another user’s experience. Accessible software respects the range of different users’ experiences, and it accommodates everyone.
As a starting point, SharePoint adopted the Web Content Accessibility Guidelines 2.0, WCAG 2.0, and set a goal for Level AA. Becoming a W3C recommendation on December 11th, 2008, WCAG 2.0 defines the expectations of and the techniques deployed in well-built, accessible Web sites. The SharePoint teams followed the spec’s developments, and we designed and tested SharePoint 2010 against the guidelines. WCAG 2.0 represents a modern, international standard that’s as valuable to developers as it is to Web users.
The four principles of WCAG 2.0 are Perceivable, Operable, Understandable, and Robust. For each area, SharePoint has made key investments, and here I’ll scratch the surface to describe a few:
We’ve tested these principles with and without Assistive Technologies to verify their value for all users.
ARIA stands for Accessible Rich Internet Applications, and it specifies descriptive extensions for Web applications. Like WCAG, WAI-ARIA is from the W3C’s Web Accessibility Initiative. In a nutshell, ARIA allows an inaccessible element, such as a div with an onclick attribute, to surface itself as a button control. This can be done with a new role attribute set to “button”—it’s that simple. SharePoint leverages ARIA in the Ribbon, in dialogs, in our new rich text editor, and elsewhere in the platform and in partner applications.
In order to keep users in context for as long as possible, we’ve introduced in-browser dialogs. With a dialog, the experience of reading, editing, and creating SharePoint content moves more quickly. Since SharePoint dialogs do not open new browser windows, we’ve built in important accessibility features to help all users navigate successfully.
As the key component of the new SharePoint 2010 user interface, the Ribbon needs to deliver powerful, useful, and usable experience. We designed the Ribbon to be accessible from the beginning, and we took advantage of multiple tools and techniques to provide a rich experience.
Keyboard support comes from the ground up. Because the Ribbon is a complicated component, it has a simple link to skip all of its commands. To help users on keyboards and alternative input devices, the Ribbon provides hidden, in-context instructions that explain its structure and how it’s controlled. Each of the Ribbon’s commands and menu anchors appear within the page’s navigation order, so it’s always safe to explore either forwards or backwards.
Because the Ribbon appears at the top of SharePoint pages, it’s necessary to provide quick access. The Ribbon operates as a central control for all of the components on the page, so it’s impractical to navigate back and forth for every command. To accelerate Ribbon interaction, a new shortcut key combination, Ctrl+[, will jump the focus to the first available Ribbon tab. From there, users can move back toward the Quick Access Toolbar commands and the Site Actions menu, or users can move ahead to the other Ribbon tabs.
In the following picture, the Browse tab has been highlighted to demonstrate focus after entering the Ctrl+[ shortcut key combination.
Similar to accessing Tabs, it’s also important to quickly access commands. For this SharePoint supports the Ctrl+] shortcut key combination. This shortcut works in one of two ways:
To move between Groups of Ribbon commands enter one of the Ctrl+Arrow Left, Ctrl+Arrow Right, Shift+Arrow Left, or Shift+Arrow Right shortcut key combinations. These shortcuts will loop through the Groups to prevent users from accidentally navigating outside of the Ribbon. The shared use of Ctrl and Shift allows for maximum browser and Assistive Technology compatibility.
Enhanced tooltips describe a command’s behavior and its availability without cluttering the user interface or slowing navigation. When trying to decipher small icons or to move between many rich commands, enhanced tooltips provide the extra bit of information needed to verify your actions.
Behind the scenes in each of the three Ribbon examples are ARIA role attributes describing the structure and purpose of the Ribbon controls. Here’s a short list of attributes:
Each of these simple strings dramatically changes how browsers and Assistive Technologies communicate Web content to users. While a basic a anchor tag will work for most basic command scenarios, it’s better and more reassuring to fully provide ARIA’s role=”button” syntax for clear descriptions.
Through investments made in InfoPath Forms Services 2010, form designers can easily design and publish forms with an accessible user experience.
InfoPath forms have been designed and tested to work with browsers and assistive technologies. Broad changes have been made to describe simple controls and complex controls with field validation and relationships.
WAI-ARIA has been used to further improve the user experience on assistive technologies: ARIA is used to notify the assistive technology of form updates, alerts, warnings, and other pop-up dialogs.
Users filling forms in IPFS 2010 have full keyboard support to access all necessary functionality. InfoPath has also done work to ensure that keyboard focus is maintained in a predictable manner during dynamic changes to the form.
Like the Ribbon, ARIA is used to achieve support for these complex requirements. Here are additional examples of how Project uses ARIA:
SharePoint’s Grid control was designed to support keyboard navigation from day one. We know that frequently when dealing with tabular data whether it is datasheets, lists or projects, users often have many items to display on screen. Because of this we provide a simple link that allows users to skip the grid when moving through elements on a page. Additionally the Grid supports many of the keyboard shortcuts you have come to expect in desktop applications. Cell navigation can be easily performed by using directional arrow keys as well as traditional tabbing. Moving up and down within grid is easy with common shortcuts like Page Up/Page Down as well as support for Home/End and many others. Support is even present for complex selection and expanding dropdowns (Alt+Down). In Project Server the control supports changing Gantt chart zoom levels all through a couple keypresses (CTRL+* & CTRL+/), as well as expanding and collapsing hierarchy.
Thanks for learning more about the investments that we’ve made to make SharePoint an exceptional, versatile, and accessible web application and platform. Web technologies move quickly, and we’re always seeking new ways to present dynamic Web experiences that work for everyone. We’re proud of the richness that we’ve delivered, and we hope that you’ll discover SharePoint 2010 to be both powerful and usable.