W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2011

PFWG review of Contacts API

From: Michael Cooper <cooper@w3.org>
Date: Tue, 23 Aug 2011 09:36:39 -0400
Message-ID: <4E53ACE7.1030305@w3.org>
To: public-device-apis@w3.org, List WAI Liaison <wai-liaison@w3.org>, List WAI PF <w3c-wai-pf@w3.org>
Below is feedback from the Protocols and Formats Working Group on the
Contacts API. Apologies that this arrives so far after the review
deadline, it takes a while to organize group review particularly in the

(1) Re: 'photos' attribute,

The spec does not allow to provide an alternate text or a description to
any of the photos. However, since the photos are meant to be used as
profile photos (explicit note provided), in general the name of the
contact person should be sufficient to be used as alternate text.

(a) The following accessibility-related problem could still occur: A
contact item has a photo, but no name and no displayName is provided
(all attributes except 'id' are optional).

* This would be a clear disadvantage to the visually impaired users.

* Proposed change: Add the following note: "If one or multiple photo
fields are provided, either the 'displayName' or the 'name' attribute
should have reasonable content, thus serving as alternate text for the

(b) It is not clear what information the 'type' attribute should carry
for a photo item. Is this intentionally left unspecified? The spec would
benefit from clarifying what information should go into the 'type'
attribute for photos, even if only by examples.

Regarding 'type' information on photos, we wonder if this information
would be useful for semantic purposes, in order to be able to
differentiate between multiple photos and their appropriate use. For
example, by marking the photos as "work", "leisure", etc., an
application could automatically suggest an appropriate photo for a
particular situation (e.g. job application, social networking site,
etc.). This would also be helpful for people with visual impairment, as
part of an automatically generated alternate text for the photos.

(2) Re: 7. API Invocation via COM Events,

* The event types mentioned include mainly mouse-specific events
(dblclick, mouseup). However, in the spirit of device-independence a
user should also be able to activate the Contact Picker via keyboard.

* Proposed change: Add "keypress" and "keyup" to the list of allowed
even types..

(3) Re: A.1 Accessing Contact Information ­ Example #1,


* In the example shown, it is not clear what the "Select" operation
applies to. Can the user select the information fields only (as shown on
the left), or can they also select and exclude individual contacts?

* Proposed change: Use checkboxes on the right side to select specific
contacts (the same as on the left side for selecting the information

(4) Re: A.2 Accessing Contact Information ­ Example #2,


* Why is there no mention of the non-blocking contact search
notification, as in example #1?

* Proposed change: Clarify.

(5) Re: Formatting issue with table header cells in the spec

Header cells in tables (like the table in 4.9.2
are displayed as inverted (white on blue). When rolling over its text,
the text color remains white and the background color is set to a light
yellow. This is not readable anymore.

The problematic layout rule is contained in
http://www.w3.org/StyleSheets/TR/W3C-WD, line 56ff:
@media screen { /* hide from IE3 */
a[href]:hover { background: #ffa }

(6) Typos

* "acheive" in Section B. Adding and Updating Contacts,


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/>
Received on Tuesday, 23 August 2011 13:37:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:49 UTC