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

On Thu, Aug 27, 2009 at 5:51 PM, Michael Cooper<cooper@w3.org> wrote:
> 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.

Fantastic.

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

Unfortunately, it's  too late to change this.

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

This seems reasonable. As we don't yet have anyone who has opted in to
implement the CC requirements, I'm wondering if we can add this. We
are debating if we should move all the conformance requirements for a
CC's out of P&C to a new spec. If we do that, we would certainly add
this to that spec.

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

Because of the way we have architectured the P&C user agent, the above
would not apply to P&C. We have removed requirements that the P&C user
agent should expose icons, license, etc. and will put those into a
separate Widget User Agent spec. To put it simply, the P&C UA is just
an application the processes Zip files and configuration documents -
that is it, does not expose or do anything else: running the widget,
exposing icons, etc. is left up to other consumers of the P&C
specification.  That new spec would also be a good place to deal with
the requirement above (i.e., make it more clear what the relationship
is between icons, name, and description from an accessibility POV. I
would very much like to collaborate with PFWG on this, but that is
future work at this point).

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

The pixel value represents the minimum value at which an icon would be
used for a given context. A vector graphic might only look good at,
for instance, resolutions larger than 100 pixels (because of
anti-aliasing, which makes things look blurry and and text illegible).
So, below 100 pixels, the author might prefer to use a raster graphic
- particularly for really small icons (e.g., 16X16).

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

Ok, for now, we have limited this to CSS pixels. In future versions,
we could allow any CSS length unit. I've added this to the V2 list of
features:

http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R

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

I agree. However, this is outside the scope of P&C. As I said above,
I'm happy to work with the PFWG on this requirement. At this point,
the P&C UA just returns a list of icons to whomever wants to use them
(as part of the configuration defaults).

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

This is not necessary with sniffing....

> It should be a requirement for a conforming
> package to be able to determine media type reliably.

Academically, yes. No widget engine on the market requires this, and
they all work just fine.

Also, I don't see how reliability increases up by giving this control
to authors? If anything, it's likely to decrease reliability as it
splits metadata from the object in question. This is a bad thing.

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

We have not come up against these. And such cases are rare.

> Beyond general use cases, the emergence of new media
> types, and widget evolution in the future, some users with disabilities
> benefit from alternate media.

This is certainly true. But sniffing new types can also be included as
needed in future UAs.

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

Agreed. But this problem is greater than what is covered by P&C 1.0. I
think we should give widgets 1.0 a chance to be out in the market so
we can find out exactly what those problems are (though I'm sure the
PFWG can probably preemptively tell us). Although we worked hard to
make the configuration document accessible, I believe current
limitation can be addressed incrementally.

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

We have explored lots of options for this, and will certainly include
it for version 2 (it's already listed as "add manifest format/addType
for mime types"). However, no implementer has request this feature.

Aside from a manifest such as the one above, we also considered
following Apache's AddType labels to identify MIME types. A
combination of all approaches (sniffing, explicit file to type
declaration) would yield something very useful, though the use cases
are still limited IMO.

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

This would certainly be good. But outdated CC's, or differences
between CC's and UAs, might cause problems: cc says "can' detect type
X, UA happily sniffs type X". However, it is certainly worthwhile
considering the low hanging fruit (e.g., just checking file
extensions, and magic numbers).

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

I'm sure there would be, but I can't think of any off the top of my
head. However, for this reason, it might be worth while looking at
systems that are already doing this (e.g., limitations/uses of appache
.htaccess files). Can you think of other systems/uses?

-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 4 September 2009 11:38:32 UTC