Re: HTML5 Image Description Extension comments

Hi Peter,

On Fri, 21 Jun 2013 01:00:59 +0400, Peter Grucza <pgrucza@gmail.com> wrote:

> I hope you don't mind a few late questions and comments on the Working  
> Draft dated 06 June 2013.

There is one potential issue in your comments. If you would like to raise  
it formally as a proposal, I have requested that you do so as an issue on  
the next published draft, which I expect to be a Last Call Working Draft  
published in 2-3 weeks. In any event, I have noted it here to make sure  
that it isn't simply lost.

> First a question about wording in part of 2. Use Cases and Requirements,  
> Requirements for an Image Description functionality. For Maintenance the  
> document states, "It /must/ be simple to maintain a library of images  
> and descriptions for dynamic assembly, or dis-assembly and re-assembly,  
> of content". For Discoverability it states, "It /must/ be simple for a  
> user agent to automatically discover a description provided for a given  
> image". Both of these use the term simple and I'm wondering if there is  
> a reason why possible isn't used in the same way that Inline or Reuse  
> have it stated. Simple just seems a big vague.

Yes, it is. The rationale is that attempts to define it more closely will  
actually be counter-productive, but making the intent clear is important.

> Also in Discoverability the following is stated, "A user /should/ be  
> able to determine that there is a description available for a given  
> image".  This concept is repeated under 3.0.3 User Agents with the  
> statement, "User agents /should/ enable users to discover when images in  
> a page contain a long description". What would the reason be for using a  
> "should" requirement level instead of a "must" requirement? Are there  
> reasons when these statements might be ignored?

This is the potentially substantive issue, of changing the requirement  
 from "should" to "must". If you would like to raise it formally, I would  
encourage you to do so as a comment on the next published draft, which  
will hopefully happen in a couple of weeks.

The reasoning is that implementors get nervous about requirements that  
they think will be interpreted as requiring specific User Interface. They  
do not want to be drawn into endless discussions about whether their  
implementation "enables the user to discover" based on the text of the  
specification.

In practice I believe it is not possible to enable the user to get to the  
longdesc without being able to discover it, given that a potential  
discovery mechanism is "try to get the longdesc for every image". That's a  
pretty unfriendly implementation (although sadly not an uncommon one). It  
seems like a bad idea to try and force quality of implementation through  
the specification, since that is more likely to lead to people arguing  
over the precise meaning of discoverable than to people spending their  
time working out better ways to do it.

> The requirement under 3.0.2 Authors states, "Authors /should/ put  
> descriptions within an element which is the target of a fragment link  
> (e.g. |longdesc="example.html#description"|) if a description is only  
> part of the target document". If this isn't a must requirement for the  
> author I'm wondering how a user agent could present the appropriate long  
> description. As an example when multiple descriptions are on a page  
> would the user agent simply present all of them from the beginning of  
> the page to the end.

A browser can move the focus to a named part of the page. If the  
description is included within an element, then it can be reliably  
extracted from the page and presented on its own.

So authors meeting this requirement allow user agent developers more  
flexibility in presenting descriptions. But in practice it is possible to  
use a page of descriptions by simply moving the focus to the relevant one.

So increasing the requirement to a must would be an unnecessary imposition  
on authors - see my comment above about not wanting to use the  
specification as the tool to force quality of implementation.

> Another situation arises when the description is on the same page as the  
> image. It would seem in this situation that the full page would be used  
> including the original image with its long description.

Again, an existing implementation approach is to open a copy of the page,  
with the focus set on the start of the description. It would also be  
possible to simply move the focus within the page, but unless the user  
understands that this has happened they may be disoriented. (Hence the  
requirement that users should be able to easily return from the  
description).

> I think there might be an implied requirement for user agents when the  
> description is in an element which is the target of a fragment link. Is  
> it expected that only the description target element be presented and  
> not other content present in the target document?

That is a possible implementation approach when authors fulfil the  
requirement. (It's one I experimented with privately, and it was easy to  
see how it could apply in many cases). But there is no "assumed  
requirement" on user agents to do so.

> Thank you for putting this document together and my apologies if I'm  
> going over items that have been raised before. I'm still trying to run  
> through the various discussions that brought this document to this point.

Thank you for your review.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 24 June 2013 11:49:33 UTC