Re: Split Issue 30?

Hi Steve,

What if one does this:

<section hidden aria-hinnen='false'>

Does it help?

Leif H Silli

Steve Faulkner, Mon, 13 Feb 2012 03:30:31 +0000:
> hi Charles, 
> 
> From testing this is what I have found [1]:
> 
> Chrome, Opera, Firefox & Safari: Content within elements that have a 
> hidden attribute are not displayed or navigable.
> 
> Note: In all supporting browsers CSS display:none is applied to 
> elements with the hidden attribute.
> 
> The fact that as currently implemented CSS display:none hides content 
> from all users is well understood and relied upon by authors.
> 
> [1] http://html5accessibility.com/

> 
> regards 
> Stevef
> 
> On 13 February 2012 03:16, Charles Pritchard <chuck@jumis.com> wrote:
>> On 2/12/2012 6:48 PM, Jonas Sicking wrote:
>>> On Sun, Feb 12, 2012 at 7:19 PM, Charles 
>>> Pritchard<chuck@jumis.com>  wrote:
>>>> On 2/12/2012 3:42 PM, Jonas Sicking wrote:
>>>>>>>  Jonas, you have a different perspective too. That's OK, too. Multiple
>>>>>>>  viewpoints are a good thing. We are fleshing out real issues in this
>>>>>>>  process.
>>>>> It sounds like your only objection to allowing aria-describedby to
>>>>> point to @hidden elements is that it will delay publishing a finalized
>>>>> HTML5 spec. That is certainly an understandable argument, though given
>>>>> the extreme inertia for changing semantics of existing features, I'd
>>>>> rather spec the @hidden attribute correction from the beginning, than
>>>>> wait to fix it in HTML6.
>>>> 
>>>> My comment was intended as: we should wait to break current 
>>>> behavior, until
>>>> HTML6. If you want to consider it like breaking a bone to reset 
>>>> it, that's
>>>> the idea.
>>>> The current situation of position, visibility: hidden and display: 
>>>> none is
>>>> well tested, and I am certainly being conservative in my position of
>>>> altering core CSS architecture.
>>>> 
>>>> As I understand it, @hidden is a shortcut for display: none, in
>>>> implementation and markup and may be implemented through the css 
>>>> selector:
>>>> [hidden] { display: none; }.
>>>> 
>>>> I'm concerned about the structural problems of altering the CSSOM 
>>>> behavior
>>>> display: none.
>>> No one is suggesting to change how CSSOM or display:none works. Please
>>> see my change proposal, it does none of these things.
>>> 
>>> It sounds to me like you are worried about various changes to the
>>> internals of browsers. So far none of the actual browser implementors
>>> have expressed this concern. In fact, both Maciej and I have said that
>>> this seems implementable and that we have to write similar code anyway
>>> to support<canvas>  accessibility.
>>> 
>>> I'd have a lot more understanding for you being concerned if you
>>> actually were implementing a browser. I much rather that we ask people
>>> who actually implement browsers what is implementable.
>> 
>> I've implemented and produced implementations of significant chunks 
>> of CSSOM and HTML Forms in Canvas, as well as implementing the 
>> various prerequisites needed for those implementations to work on a 
>> variety of existing graphics APIs.
>> webkit uses display: none for @hidden.
>> 
>> The Canvas accessibility mod involves only re-basing 
>> HTMLCanvasElement. It does not involve dynamically re-basing the 
>> inheritance chain of arbitrary elements. Maciej has not, as far as I 
>> can tell, worked on Canvas accessibility code.
>> 
>> My concern isn't implementation. It's the consequences that changing 
>> the rules would have for web authors.
>> For one thing, they'd be able to focus on display: none elements.
>> 
>> If that's not the case, then @hidden is being split from the 
>> display: none semantic, and that is the crux of your proposal:
>> @hidden is a new semantic, and not a short-cut for display: none. 
>> And if that is truly the case-- then I'm less alarmed, though this 
>> does introduce a new semantic.
>> 
>> 
>>>> I'm concerned that encouraging display: none for perceivable content may
>>>> lead to a digital divide for users of older browsers and ATs.
>>> This seems like an argument against adding any features to HTML5 or
>>> any other standard to improve accessibility. Since any time you do
>>> that you risk increasing the digital divide since only newer browsers
>>> would support said standard.
>> 
>> No, it's an argument against changing display: none. I've been doing 
>> just fine keeping my compatibility layers from HTML3 - HTML5.
>> 
>> 
>>> You are of course entitled to your opinion. But I strongly disagree
>>> with it. Especially in the context of writing new webstandards which
>>> is what this mailing list is about.
>> 
>> I was under the impression that HTML5 is under last call, and that 
>> we're trying to finalize an existing web standard.
>> ... That's not to exclude discussion of HTML6.
>> 
>> -Charles
>> 
> 
> 
>

Received on Monday, 13 February 2012 10:19:34 UTC