[CEUD-ICT] Accessibility of multiple main headings in HTML5 webpages

[Joshue O Connor]

Hi Alan,

I am on hols at the moment, but I couldn't resist this one...

> I'm wondering about multiple main headings in HTML5 webpages, and how
> accessible they are for assistive technology users today.
> 
> The HTML5 specification allows a webpage to have multiple "article"
> elements. 

The term 'article' should be understood to not just mean an 'article'
(in terms of a newspaper article) but an 'item'. It denotes an object,
item or part - with a high level of granularity. It can represent any
discrete item.

> Each "article" element can have a main heading, marked as <h1> in
> the source code. A main heading in an article in an HTML5 webpage is only a
> main heading for the content of that article; it is not a main heading for
> content of the whole webpage. This is very different to the approach in
> HTML 4.01 and XHTML 1.0, where each webpage typically has only one main
> heading for all its content [1].

Yes it is!

> Having multiple "article" elements, each with its own main heading, seems
> very practical. A lot of modern webpages (such as blogs) are basically a
> collection of articles from various sources. With HTML5, a webpage author
> can copy an entire article from somebody else's webpage, and paste it
> directly into his own webpage, without having to worry about the structure
> of his webpage.

Yes [but]!! In accessibility terms VIP screen readers users are
certainly used to the rather simple 'here is a HTML page with 1 <H1>,
and several <H2>s etc' model. That's not going to be the way it works
with HTML 5. The interesting thing is that I have no idea how AT vendors
like Freedom Scientific will implement the spec in their product. Will
the AT mediate the complexity brought on by /advances/ in the spec? Will
users need to become more 'html aware' to navigate even rudimentary
webcontent? These are very interesting questions that I look forward to
finding out the answers to by practical testing :-)

> Mark Pilgrim explains how to use multiple main headings in HTML5 webpages,
> in his "What Does It All Mean?" article [2]. He compares an XHTML 1.0
> version of a weblog with an HTML5 version. Here's a simplified version of
> his XHTML 1.0 version [3] :
>       <div>
>             <h1>My Weblog</h1>
>       </div>
>       <div>
>             <h2>Travel day</h2>
>             <p>Lorem ipsum ... </p>
>       </div>
>       <div>
>             <h2>I'm going to Prague!</h2>
>             <p>Lorem ipsum ... </p>
>       </div>
> Here's a simplified version of his HTML5 version [4] :
>       <header>
>             <hgroup>
>                   <h1>My Weblog</h1>
>             </hgroup>
>       </header>
>       <article>
>             <header>
>                   <h1>Travel day</h1>
>             </header>
>             <p>Lorem ipsum ... </p>
>       </article>
>       <article>
>             <header>
>                   <h1>I'm going to Prague!</h1>
>             </header>
>             <p>Lorem ipsum ... </p>
>       </article>
> 
> What do you think of the accessibility of this, considering the skills,
> expectations, and software that assistive technology users have today? 

For a start the way users will interact with webcontent is going to
change. We are used to browsing by headings, links etc. That will still
be possible but there will be also be the ability to extract <article>,
<aside>, <section>, <nav> elements and other attributes such as WAI
ARIA, aria-describedby, aria-labelledby, ARIA LiveRegions etc.

So I guess, users will be potentially able to extract <article> elements
into a dialogue box rather like they do now, and then be able to
navigate to any child content of the containing parent element. The same
for the <section> element etc. FWIW, I do think there is going to be a
lot of confusion of exactly /how/ to apply all of these elements. This
can be expected in anytime of change and the good news is that the
toolkit and its ability is expansive but again there is a wee learning
curve yet to be dealt with!

Part of the 'problem' is that HTML is no longer /just/ a declarative
markup language but rather is is also a very sophisticated amalgam of
APIs such as <canvas>, <video> etc. FWIW I wonder if there is just too
much going on (there is a certain degree of duplication between elements
and their functionality but again the spec is pretty explicit about how
each element etc can be applied) but only time will tell how this will
effect the end user.

As I alluded to earlier the interesting issue for me is how AT vendors
will implement HTML5 features. We have seen a wide uptake of parts of
WAI-ARIA already in many of the main browsers, as well as in AT but as
of yet I haven't seen much in terms of HTML 5 implementation. The spec
proposes and the vendors dispose, so the spec is really just a document
containing a series of recommendations/algorithms/behaviours/rules and
their contexts and then the world decides to react or not.

Anyway if it all goes Pete Tong, at least we have HTML 4 :-)

My 2 cents

Josh

********************************************************************
National Council for the Blind of Ireland (NCBI) is a company 
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626). 

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************