Re: [updated] proposed rewording of ISSUE-204 text

Edward O'Connor, Tue, 11 Sep 2012 16:52:40 -0700:

> Here is a small revision of that text which attempts to address several
> of the concerns that have been raised in Bugzilla[2] and here on
> public-html:

Hi, Ted. Some notes in the middle of the proposed text plus a note on 
the principles at the bottom.

>> Accessibility APIs are encouraged to allow a way to expose structured
>> content while marking it as hidden in the default view.

WHen I read "to expose structured content", I wonder: Expose as what? 
As structured content - or to expose at all? Like I said in the bug: 
For aria-describedby, there is a choice: Either as structured or as 
flattened. But, for example for image maps, is there such a choice? It 
would be very insufficient to expose an image map as "flattened". And, 
with regard to hidden table header cells: Does VoiceOver (which do 
this, not?) expose the header _relationship_? If yes, then _that_ is 
structure. But does it also expose e.g. links inside the hidden header 
cells? Or, does it _only_ refer the internal structure but not the 
relationship? Some loose ends here I feel, so far.

Also: If the alternative to render full semantics is to render nothing 
at all - no rendering, then what? In such a case, it is hardly relevant 
whether the content is authored to work well under plain text 
conditions! (This relates to the last paragraph in the proposed text.)

>> Such content
>> should not be perceivable to users in the normal document flow in any
>> modality, whether using Assistive Technology or mainstream User
>> Agents.
>> 
>> When such features are available, User Agents may thus expose the full
>> semantics of hidden="" elements to Assistive Technology when
>> appropriate, if such content is referenced indirectly by an ID
>> reference or hash-name reference. This allows Assistive Technologies
>> to access the content structure upon user request, while keeping the
>> content hidden in all presentations of the normal document flow. Some
>> examples of where it would be appropriate for the structure of
>> hidden="" elements to be exposed to users of AT with such an API
>> include:
>> 
>>  * a <map> referenced from <img usemap>
>>  * table headers referenced with the headers="" attribute

I just came to think that <canvas> would be a natural element to 
mention, in addition to the above. Please consider. The fallback of 
<canvas> serves as an example of content that is alternative content 
and of content that is indirectly referred by being *contained* inside 
<canvas>. <canvas> is very similar to image maps, in a way.

>> Cases where it would be inappropriate for the structure of hidden=""
>> elements to be exposed to users of AT with such an API include:
>> 
>>  * a hidden="" element referenced by <a href> within the same document
>>  * a hidden="" form element referenced by <label for>
>>    Note: The sorts of elements referenced from <label for> cannot be
>>    flattened without losing essential meaning (see below).
>> 
>> Other specifications which define elements and attributes which may be
>> included in valid HTML documents (such as SVG, MathML, and WAI-ARIA)
>> may define how or whether this applies to their elements and
>> attributes.
>> 
>> Because historically some User Agents have flattened hidden content
>> when exposing such content to Assistive Technology, authors SHOULD NOT
>> reference hidden="" content which would lose essential meaning when
>> flattened.

Like I said above: This warning speaks against revealing image map 
elements, does it not? The text blus hidden="" and "hidden". You could 
perhaps alter the last paragraph to say for example the following: 

   "_When hidden content serves as alternative content_, then authors 
MUST author it accordance with the relevant rules for providing 
alternative content. However, because some User Agents historically 
have flattened [… same text as now].

> Changes (with rationale) described below.
> 
> Leif wrote, in [3]:
> 
>> Summarized, we could say that Ted’s new text recommends that, in case
>> of indirect relations between hidden *labels/captions* and some
>> visible content then the hidden label/caption content should be
>> exposed. Whereas when visible label/caption content reference hidden
>> *content*, then the hidden content should not be exposed. Could a
>> summary along those lines be added to the text?
> 
> I'm not sure that accurately captures the principle at heart, but I've
> tried to rework the text a bit to make it more clear.

Thanks for taking in much of what I proposed - the text is more 
symmetric now.

But regarding principles: I agree that I had not captured them well. 
But now, because of the discussion that took place in the bug, I have 
an idea of the principles even if they are not expressed so clear that 
one could wish in the text. But for someone reading the above text with 
more distance to it, I would have liked more help in seeing the 
principles - whatever is the best description of them. I mean, if we 
want to show to WAI-ARIA and SVG what *we* have done, so that they may 
follow - if they want - we should be clearer, I think.

For example the text say this:

>> Other specifications which define elements and attributes which may be
>> included in valid HTML documents (such as SVG, MathML, and WAI-ARIA)
>> may define how or whether this applies to their elements and
>> attributes.

Especially the phrase "whether _this_ applies to their elements and 
attributes". This what? The - somewhat "lofty" idea that certain hidden 
content could be unhidden - with semantics - when needed? I would 
propose to edit that paragraph somewhat. ANd I would also propose a new 
paragraph *before* that paragraph, which describes the principles of 
*HTML* (not of SVG, WAI-ARIA etc, but of HTML5). In the following 
proposal, I use <del> and <ins> to _highlight_ important changes [there 
are more changes too, according to what I find natural language]):

   ]]
     <ins class="HTML5’s-principles">
     The kind of hidden content for which exposure is recommended is
     for example hidden nodes that are indirectly referred to by that
     HTML feature that has the current focus, provided that HTML 
     specifies that the references implies an advisory, captioning or
     or alternative content relationship to the current focus.
     </ins>

 [Of course, the above paragraph could go before the examples instead.]

     For <ins>applicable</ins> specifications (for example SVG,
     MathML and WAI-ARIA) that define elements or attributes
     which may be included in <del>valid</del> HTML, <del>may</del>
     these specification themselves regulate how or whether to
     encourage Accessibility APIs to expose the structures of 
     hidden content.
  [[

Note that I said 'applicable specifications' instead of "valid HTML 
documents". Because what is valid HTML documents? The spec uses, when 
it comes to extensibility, the phrase "applicable specifications". I 
think that would be a better phrase as "applicable" covers both "HTML5 
valid" and specs that possibly/hypothetically apply from other angles 
than "HTML5" (that is: specs that are not necessarily covered by the 
HTML5 validator, for example).

-- 
leif halvard silli

Received on Wednesday, 12 September 2012 04:30:10 UTC