Re: accessibility support for nested h1 in sections?

On Sat, 23 Jan 2016 19:10:00 +0100, Mike Elledge <melledge@yahoo.com>
wrote:

> Hi All--
>
> So would the appropriate way for a screen reader to respond be to state  
> "Section X" followed by "heading level one" in a flat H1 scenario?
>
> This doesn't seem like rocket science; why hasn't it been implemented by  
> browsers?

No, the goal of the all-h1 scenario is that for a section with h1 that is  
nested inside a section with an h1, the inner section's heading would be  
treated as an h2 - or h3 or whatever, depending on the level of the  
nesting.

Browsers *have* applied a stylesheet to make the visual appearance seem  
that this happens. But it is pretty naive. In particular, it assumes that  
authors who use the nested h1 approach use the equivalent approach in  
stylesheets if they do anything to headings.

So what a browser should pass to the screen reader is that the nested  
heading is level 2.

That still isn't rocket science. It involves applying a heuristic to  
determine the author's intent, and while that is always a dicey  
proposition, it is probably pretty reliable for this case in practice.

As far as I know, no browser provides a native tree-walk that lets authors  
swap between depth-first and breadth-first, which is what people do when  
navigating trees in many applications. If they did, the information about  
nesting level would be important - as it is to any extension or other app  
that provides this.

That too is feasible. Although painful in a large document, it might be  
worthwhile, given that a document large enough to affect preformance  
seriously is probably also large enough that it is a real enhancement of  
*actual* performance for the user. That is, the slowdown in the browser  
would not be noticed, but the speed-up given to the user by letting them  
navigate efficiently would be.

Consider the HTML specification, or WCAG techniques document,  as relevant  
examples. Being able to open one, skip from chapter to chapter and then  
into sections and subsections as you find the chapter/section/subsection  
you want would be a big help in certain scenarios.

It is true you can use the table of contents - but it turns out that even  
navigating that is painful - which is why there is a table of contents for  
the table of contents in HTML, and a filtering system for WCAG techniques.

With the system h1-h6 that has been in place since the beginning of HTML  
there are also issues. There have been a couple of attempts to do the  
all-h1 trick by introducing a new h element, but they foundered on browser  
implementation and the fact that it isn't really backward compatible  
(although that can be prollyfilled for most use cases).

The question is whether the half-half approach if nested h1 has brought us  
any real benefit, or should be abandoned as another failed experiment -  
which in turn brings up the question of how widely it has been deployed in  
content and tools taht are hard to change…

cheers

> Mike
>
>> On Jan 22, 2016, at 6:25 AM, Patrick H. Lauke <redux@splintered.co.uk>  
>> wrote:
>>
>>> On 22/01/2016 11:03, Chaals McCathie Nevile wrote:
>>> So as I read it, "most" browsers are using a nice CSS trick to make
>>> headings get smaller, but they are not actually providing the semantics
>>> and therefore presenting the *wrong* information to e.g. accessibility
>>> APIs.
>>
>> Correct, it seems the situation is still pretty much as Steve wrote a  
>> few years ago...
>>
>> https://www.paciellogroup.com/blog/2013/10/html5-document-outline/
>>
>> http://adrianroselli.com/2013/12/the-truth-about-truth-about-multiple-h1.html
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>


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

Received on Monday, 8 February 2016 19:57:34 UTC