PF Comments on social media

Below is the information about accessibility that the Protocols and
Formats Working Group suggests the Social Web Incubator Group
incorporate into its report. It may be appropriate to adjust the wording
to fit with the rest of your content, but we hope you can retain the
information. PF approval to send these as formal WG comments is archived
at http://www.w3.org/2010/07/21-pf-minutes.html#item08 (Member-only link).

In a review, it did not appear that Social Web sites have accessibility
issues intrinsically unique to social media. However, social sites share
characteristics with other types of Web content that have known
accessibility issues. Most important, social sites tend to 1) be
dynamic, with sometimes multiple areas of content changing without user
mediation; 2) be highly customized, providing page features that are not
standard parts of the underlying content technology and therefore don't
have accessibility features provided by the underlying architecture; 3)
rely on user-contributed content, which needs supports to ensure users
can contribute accessible content. The issues of dynamic content are
addressed by the Web Content Accessibility Guidelines
<http://www.w3.org/WAI/intro/wcag>, particularly Success Criteria 2.1.1
Keyboard, 2.4.3 Focus Order, 3.2.1 On Focus, 3.2.2 On Input, and 4.1.2
Name, Role, Value. The use of custom page features can be made
accessible by use of Accessible Rich Internet Applications
<http://www.w3.org/WAI/intro/aria>. Accessibility of user-contributed
content is addressed in Authoring Tool Accessibility Guidelines
<http://www.w3.org/WAI/intro/atag>, particularly (from the ATAG 2.0
draft even though it has not yet superseded the ATAG 1.0 Recommendation)
Success Criteria B.1.2.1 Preserve Accessibility Information, B.2.1.1
Decision Support, and B.2.1.2 Set Accessible Properties. APIs provided
by social sites also need to provide full support for accessibility
features; a robust API can enhance accessibility by allowing the
creation of accessible alternate user interfaces.

The accessibility issues of authentication mechanisms tend to be
implementation specific, and the basic principles are addressed in Web
Content Accessibility Guidelines <http://www.w3.org/WAI/intro/wcag>,
particularly Success Criteria 2.2.5 Re-authenticating, 3.2.1 On Focus,
and 3.3.2 On Input. It is important that authentication implementations
do not unexpectedly redirect users e.g., to a third party authentication
site, and that modal authentication dialogs work properly for
keyboard-only, mouse-only, and mouse-and-keyboard users. Reliance on
features such as cross-site scripting and third-party cookies may
exclude a greater proportion of people with disabilities than of the
general population, because of lack of support by assistive technologies
for these features. Authentication registration processes often need to
verify identity or at least exclude robots from registering. CAPTCHAs
are widely relied upon for this but present significant accessibility
problems as described in Inaccessibility of CAPTCHA
<http://www.w3.org/TR/turingtest/>, which need to be addressed in
implementation.
-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>