Re: Review of Section 7.1 by ARIA working group in PF

(chair hat off, just technical comments)

On Oct 12, 2012, at 6:30 PM, John Foliot <john@foliot.ca> wrote:

> Maciej Stachowiak wrote:
>> 
>> 
>> Are any of these different from the implied automatic consequences of
>> hidden elements having display: none style?
>> 
>> - Maciej
> 
> Hi Maciej,
> 
> As I have already noted (asked?) elsewhere, with the proposed changes to
> @hidden, and its ability to now expose some rich content to ARIA, would the
> default Browser CSS will also likely have to be re-worked, as currently all
> screen readers respect {display:none} as content that is not there, and thus
> not read aloud. 

I don't see any reason the default style for hidden content would need to change.

> 
> I had previously asked
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277) if instead it would
> thus now be closer to {visibility:hidden; height:0; width:0;
> overflow:hidden} (conceptually a "black-hole" that could still contain
> content).

I think that style would not be good; it would likely result in content marked this way being read aloud by screen readers in the normal flow, which is not desired.


> 
> I have only heard from Henri, who if I am to understand his response, also
> notes that the default CSS rendering rules (with regard to the visual
> viewport versus outside of that viewport) would also need to be redefined
> with regard to ARIA mapping/exposure.

I believe Henri's response just says that "display: none" is not an obstacle to rendering other than in the default CSS viewport (such as in an out-of-band popup or as part of a requested description in a screen reader).

> 
> 
> Finally, his suggestion of: 
> 
> 	"<div hidden style="display: block !important;">This should render
> in a CSS view port.</div>" 
> 
> ...would also remove the restrictions that are currently staking up against
> this technique: if it is rendered on screen, then all of the previously
> disabled 'focusable' elements could now take focus.

I would expect tab focus to be allowed for form controls inside that div, because the CSS style would make it effectively not hidden. Would you want or expect otherwise?

> 
> I will note in passing here that this is also significantly related to my
> current Formal Objection to Issue 204 (the tab focusable content problem),
> and if we can get this resolved in a timely manner, it would allow me to
> withdraw my Formal Objection in advance of TPAC. I am mindful however of not
> getting that cart before the horse, and so any effort that the Chairs can
> apply to a speedy resolution here will also unblock other efforts elsewhere.

I have to admit I am not totally clear on the proposed change or what relationship it bears to your objection. 

Reading closer I see that Cynthia's document includes a table of methods, but I am not sure what it is intended to mean. When it says the element click method should be disabled on hidden content, is it referring to elements getting normal click events from the UI, or a literal call to the DOM click() method from JavaScript? I do not understand the motivation for the latter or how it relates to tab focus. The click() method can be called on members that are display: none or are not in the document flow at all, so I don't understand why it would be restricted for hidden elements. Can you or Cynthia explain what is intended and give the rationale?

Regards,
Maciej

Received on Saturday, 13 October 2012 01:40:47 UTC