PFWG comments on Widgets 1.0: Packaging and Configuration Last Call (late, very late)

This is a review of Widgets 1.0: Packaging and Configuration
<http://www.w3.org/TR/2009/WD-widgets-20090528/>, the Last Call Working
Draft. These comments are submitted on behalf of the Protocols and
Formats Working Group and are focused on accessibility to people with
disabilities.

We apologize for sending these comments late, after the document has
gone to Candidate Recommendation. We approved sending these comments on
17 June 2009 http://www.w3.org/2009/06/17-pf-minutes#item04, but failed
to track that they actually got sent. Since the document progressed to
Candidate Recommendation before we discovered the error, we understand
that you may not be able to accommodate most of these comments. However,
we believe it is important to put the comments on the record
nevertheless. You may be able to address some of them as editorial items
on the Candidate Recommendation, and the remainder could inform
requirements for a future version. We do not, however, object to this
version of the document proceeding to Recommendation as is, since the
failure to send comments on time is ours.

1) Text alternatives

An object as complex as a packaged widget will certainly need a text
alternative or label for accessibility. The possibility for this is
provided with the <name> element (including the "short" version) and the
<description> element. However, these are optional features of the
configuration document. The <name> element should be required; in other
words, there should be 1 or more, not 0 or more. The <description>
element could remain optional. In addition to enforcing this,
conformance checkers should also raise a warning if there is not a
<name> element provided for each localization, at least for every major
language (may not be a huge issue for regional variants).

The <name> element for the widget would also fulfill the role of a text
alternative / label for the icon. In particular, the "short" name might
serve as a good label, while the longer name serve as a text alternative
for accessibility purposes. The <description> would also be something it
would be important to expose to assistive technologies. This handling of
icons should be clearly spelled out.

2) Width and height attributes

The "width" and "height" attributes only allow pixel values. Pixel
values are notoriously problematic across device and user contexts.
Furthermore it is odd that these attributes are limited to pixels when
they are explicitly disallowed when a pixel-based raster graphic is
used. If the author is using a vector format, why would they then
restrict it to a specific pixel value?

Users with disabilities frequently need to customize size presentation.
While user agents can be instructed to ignore pixel values or apply a
multiplier to them, the results are often sub-optimal. It is better to
allow the author to define more adaptable length units. Measurements
such as inches and centimetres adapt better to various display devices
then pixels; ems and percent adapt better to specific display contexts.
While in a packaged widget, the context needed to resolve ems and
percent units may not always be present, it often will be. Therefore, we
suggest that the entire set of CSS length units be supported by these
attributes.

3) Icon alternatives

The example in 8.10 suggests it's possible to provide more than one icon
element per localization, for e.g., different sizes (other domains of
difference are not spelled out). How does the user agent select which
icon to use? How might user preferences or context impact this? That
needs to be spelled out. Users with disabilities should have the ability
to influence which icon is presented to them via user agent preferences,
and the icon selection procedure needs to be specified to support this.

4) MIME type detection and support for additional media types

The specification defines file extension mapping and content sniffing
procedures, as there is no way to define media types in zip files.
Wouldn't it be a point of the packaging format to provide explicit media
type information in the package? It should be a requirement for a
conforming package to be able to determine media type reliably. While
file extension and magic numbers are useful for formats that have
defined processing, there will certainly be use cases to provide content
in media types not supported by these mechanisms. Beyond general use
cases, the emergence of new media types, and widget evolution in the
future, some users with disabilities benefit from alternate media. There
would certainly be reasons to package widgets with capabilities provided
by alternate media such as audio or video, even if they are for
specialized audiences.

We suggest providing the possibility of including a file catalog that
explicitly provides the MIME type for files whose type would not be
detected by the methods defined in the spec. It could be as simple as:

file: catalog.xml
<catalog>
<file path="{Path attribute}" type="{Media type attribute}"/>
...
</catalog>

It need not be a requirement that the catalog list all files, only ones
that need special information attached. Conformance checkers should
check that the MIME type of every file can be determined reliably,
either via the sniffing mechanisms already defined or via an entry in
the catalog file.

There may well be other types of special information that the catalog
might support, once introduced. So the benefits of providing this
probably extend beyond improved MIME type detection.
-- 

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/>