[via Lawrence]
One of the most annoying SharePoint 2003 things was the way SharePoint pages are built and how the CSS classes are used through the pages. I already wrote something about that in the past. With the masterpage construction in SharePoint 2007 (asp.net 2.0), a lot of these CSS problems can be resolved. Lawrence Liu wrote an article that descibes some other usability improvements which are a good step forward:
“We have been getting quite a few questions via blog feedback e-mails about accessibility, so I wanted to share the following summary of new and improved accessibility features that the WSS V3 team is working on, which are of course leveraged by Office SharePoint Server 2007 as well. Things can still change between now and RTM, so please don’t take the following list as a promise of full compliance. Nevertheless, the Windows SharePoint Services and Office SharePoint Server product teams are definitely committed to improving accessibility and enabling all customers to utilize the power of SharePoint Products and Technologies.
Headings
· Table headings on important data tables (TH tags). This helps users understand the structure of a table and improves the reading experience for screen reader users.
o This relates to WCAG 1.0 Checkpoint 5.1: For data tables, identify row and column headers. [Priority 1]
· Headings markup on important content (H1-H3). This helps screen reader users better understand the layout and structure of our pages.
o This relates to WCAG 1.0 Checkpoint 3.5: Use header elements to convey document structure and use them according to specification. [Priority 2]
Navigation
· ‘Skip to main content’ links to help visually impaired users quickly jump to the most important content without having to tab through our navigation links.
o This relates to US Section 508 paragraph 1194.22 (o): A method shall be provided that permits users to skip repetitive navigation links.
· Standard navigation bread crumb to assist with site navigation and orienting users on where they are in the site.
o This relates to WCAG 1.0 Checkpoint 13.4: Use navigation mechanisms in a consistent manner. [Priority 2]
Keyboard
· Smarter and more intuitive use of access keys on common commands.
o This relates to WCAG 1.0 Checkpoint 9.5: Provide keyboard shortcuts to important links. [Priority 3]
· All UI controls in the application will be keyboard accessible.
o This relates to WCAG 1.0 Checkpoint 9.2: Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2]
· Improved, more intuitive keyboard tab order.
o This relates to WCAG 1.0 Checkpoint 9.4: Create a logical tab order through links, form controls, and objects. [Priority 3]
Graphics
· Better use of ALT descriptions on images.
o This relates to WCAG 1.0 Checkpoint 1.1: Provide a text equivalent for every non-text element. [Priority 1]
· Images that can be uploaded to the site allow for a UI based way to define custom ALT text for that image so that blind users can interpret what the uploaded images are.
· We provide warnings (through ALT text on image links and title attributes on text links) for links that will open a new window to help reduce confusion and improve the user experience.
o This relates to WCAG 1.0 Checkpoint 10.1: Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]
High Contrast and Low Vision
· High contrast testing for low vision scenarios.
o This relates to WCAG 1.0 Checkpoint 2.2: Ensure that foreground and background color combinations provide sufficient contrast. [Priority 2 for images, Priority 3 for text]
· We do not rely on the use of color alone to convey information.
o This relates to WCAG 1.0 Checkpoint 2.1: Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1]
HTML controls
· We also have a “more accessible” mode that allows users with special needs to identify themselves so that we can change the way some of our dynamic content is rendered (for example we will render our Javascript menus as plain HTML links in a new window when the user activates this mode making it easier for them to interact with the menu). We also render custom form controls as standard HTML controls so that they will be better recognized by the accessible technology.
· "More accessible mode" is exposed via the Object Model so that third parties can create solutions catered to screen reader users.
· Proper MSAA names on all editable controls, links, and buttons.
· Screen reader friendly Instant Messaging presence status and menu interaction on presence enabled people fields. We’ve added ALT text that describes the presence status on people fields on the site, and made ENTER the action of opening the menu for these to simplify the keyboard only experience. “
Read complete article