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

I think that interactive content within a @hidden area is not ready for implementation, and it seems highly unlikely that we would have two interoperable implementations before 2014.  On Windows, this feature would likely require API changes in the operating system.  Since we just shipped Windows 8, that is a way off.  Even for AT that use the DOM rather than platform accessibility APIs, there would need to be work done in the AT products to enable this feature.  AT products have long development cycles.

On the html-a11y call this morning, we were discussing the possibility of using the new Shadow DOM spec for some of these use cases, rather than using references to hidden content.  That seems like a good avenue to pursue, but again, doesn't seem fully developed enough for a the main HTML 5 spec in the 2014 timeframe.  I think it makes sense to move this work to v.next or an extension spec.

The goal of this change is to clarify that pointing to hidden, interactive content is not supported for HTML 5, and what it means to not be supported.

More inline....

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Friday, October 12, 2012 6:40 PM
To: John Foliot
Cc: Cynthia Shelly; 'Edward O'Connor'; public-html-a11y@w3.org; Paul Cotton; 'Sam Ruby'
Subject: 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.
[Cynthia Shelly] They are not different than what is implied by display:none as far as I know.  However, I don't believe the behavior of interactive elements within a display:none area is well specified, so I wouldn't be surprised if some of these things are currently not disabled in all browsers.  They do not receive focus in the tab order, but I have not tested whether they can receive focus or clicks via DOM methods.  I propose that this be disallowed for both @hidden or display:none.

> 
> 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?
[Cynthia Shelly] It is not a good idea to have hidden elements taking focus.  I would call hidden display:block an authoring error.  What is the use case for this?

> 
> 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?
[Cynthia Shelly] 
I meant the DOM methods.  This should not be allowed on hidden or display:none content.  Currently, focus fails for display:none in Chrome, FF, and IE, and for hidden in Chrome and FF.  click works, but I don't think that it should.  I haven't tried the others.

Regards,
Maciej

Received on Thursday, 18 October 2012 17:50:20 UTC