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

Thank you for your responses to our comments. The PFWG formally accepts
your disposition of these issues. There is some discussion inline below
as input into requirements for future versions of the spec.

Marcos Caceres wrote:
> 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.
>   
Understood and accepted. Can this be a feature request for a future version?
>   
>> 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.
>   
Sounds like a decent approach. You separately referenced a draft at
http://dev.w3.org/2006/waf/widgets-pc-cc/Overview.src.html. I would be
happy to provide individual input on this; PFWG will probably not be
formally involved.
>   
>> 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).
>   
Ok. Understood and accepted.
>   
>> 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).
>   
Ok. Understood and accepted.
>   
>> 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
>   
Ok. Understood and accepted.
>   
>> 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).
>   
Ok. Understood and accepted. I'm happy to work on this individually with
you.
>   
>> 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.
>   
Ok. We can appreciate that the scope of this is beyond 1.0. We believe
there are more use cases than you might have considered, for example
video help for people with learning disabilities or video sign language
tracks for deaf users. We could help you brainstorm use cases at some
point. In general, use cases that are important for accessibility seem
"fringe" at first, but in the long term prove to have value to the
mainstream as well. So even if the market for some use cases seems
small, there is still value in engineering for it, or at least not
engineering against it by accident. PFWG has formal interest in
continuing discussion on this.
>   
>> 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?
>
>   
Understood and accepted with the explanations above. We didn't have
specific additional uses for a catalog in mind when suggesting it, but
generally observe the usefulness of them. We may be able to help come up
with uses in a brainstorming session.

Since a few of the responses include a suggestion to brainstorm
together, perhaps there would be an opportunity to do so at the upcoming
TPAC meeting? If you're too busy to do this in the near future I'm sure
it can wait. PFWG is interested in engaging with you on this technology,
as we see it being important down the road.

Michael
-- 

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