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

Hi Michael,
WebApps is awaiting on a response from WAI before we republish the
Widgets P&C specification.

FYI, as I alluded to in my previous email (below), we have created a
new document for conformance checkers:

http://dev.w3.org/2006/waf/widgets-pc-cc

Again, I would be happy to collaborate with someone from WAI on that document.

Kind regards,
Marcos

On Fri, Sep 4, 2009 at 1:37 PM, Marcos Caceres <marcosc@opera.com> 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.
>
>> 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
>



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

Received on Saturday, 3 October 2009 16:51:17 UTC