Re: PFWG review of Contacts API


Thanks to you and the Protocols and Formats Working Group for these comments.

I have entered this in the Last Call tracker as LC-2547,

The WG has not yet had a chance to discuss but will do so.


regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group

On Aug 23, 2011, at 9:36 AM, ext Michael Cooper wrote:

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 summer.

(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,č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 fields).

(4) Re: A.2 Accessing Contact Information ≠ Example #2,č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, 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
Information Page<>

Received on Thursday, 25 August 2011 20:26:43 UTC