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

[Alan M. Dalton]

Hi Eamon,

Thanks for the post; you made some interesting points there.

Because WAI-ARIA and HTML5 are so new and relatively untested, I think web
developers who are using AJAX techniques in their websites will have to
carry out user testing with people with disabilities to make sure that
their websites are accessible.

Regards,
Alan.
_
Alan Dalton
Accessibility Development Advisor for EtA http://www.nda.ie/eta
Access Officer for NDA http://www.nda.ie

Address: National Disability Authority, 25 Clyde Road, Dublin 4.
_


                                                                           
             Eamon Doyle                                                   
             <eamondoyle at gmail                                             
             .com>                                                      To 
             Sent by:                  Centre for Excellence in Universal  
             ceud-ict-bounces@         Design ICT mailing list             
             list.universaldes         <ceud-ict at list.universaldesign.ie>  
             ign.ie                                                     cc 
                                                                           
                                                                   Subject 
             06/08/2010 21:21          Re: [CEUD-ICT] Accessibility of     
                                       multiple main headings in HTML5     
                                       webpages                            
             Please respond to                                             
                Centre for                                                 
               Excellence in                                               
             Universal Design                                              
             ICT mailing list                                              
             <ceud-ict at list.un                                             
             iversaldesign.ie>                                             
                                                                           
                                                                           




Hi folks

My first post... Unfortunately it's a very long one, but hopefully it has a
point :)

Another challenge that lies ahead is how screen reader users adapt to using
WAI-ARIA.

I've been away from "full time" Web Accessibility development for about 12
months now, so I'm still getting up to speed on ARIA.
However here's my understanding of how things stand, but by all means feel
free to clarify any inaccuracies.

Most of us would have read and followed the techniques derived from the
WCAG 1.0 guidelines (from circa. 1999).
Since these were developed 11 years ago, they mainly focused on static "Web
Content."

Due to the limitations of browsers (e.g. inconsistent DOMs) and
accessibility APIs (such as MSAA) screen readers had a hard time extracting
meaningful information from a web page.

What goes on "under the hood" is something like as follows:
A user lands on a text input field. The browser informs the screen reader,
via the API, what the "role" of this field is, what it's "state" is
(enabled, disabled, read-only etc), and some additional attributes e.g.
it's value.
The API passes this information to the screen reader.

A problem arises when the "role" of certain elements aren't defined in the
API. For example, AFAIK, MSAA doesn't have mappings to define headings,
lists, tables etc.

As a result Assistive Technology vendors had to introduce a new concept for
web browsers usually referred to as the "virtual buffer". JAWS calls this
"Virtual PC Cursor" and Window Eyes calls this "Browse Mode".
A virtual buffer is essentially a snapshot of a web page at a given point
in time (often on page load).
This is the usually the default mode used (automatically) but there are 2
other modes - e.g. in JAWS you have "PC Cursor mode" and "Forms mode",
where the "live" document is used (not a snaphot).

So why is a snapshot needed?
A snapshot allows the screen reader to build up it's own "model" of the
page. It can "slice and dice" the HTML in whatever way it wants.
      In this mode, users can use the arrow keys to read through a
      document, without moving the visible system caret (i.e. the screen
      reader focus is different from the system focus)
      It allows access to static (normally) non-focusable text by
      simulating an insertion point/caret.
      It can be used to nagivate/read by word, line, sentence, paragraph,
      links, headings etc. using certain keyboard combinations e.g. INSERT
      +F6 in JAWS displays a list of all headings.

However, it has a problem... What happens when the HTML changes dynamically
(via JavaScript/Ajax)? The snapshot is now out of synch with the "live"
document. And this is the problem that ARIA is hoping to solve, in a very
intelligent way I might add.
The core of ARIA involves defining about 60+ roles and states explicitly in
the HTML. One of which includes a role for "live regions" for content that
was been updated and delivered from the web server via Ajax.

However, and this is what prompted my reply, using WAI-ARIA  requires the
Screen Reader to avoid using a virtual buffer.
Instead the "PC Cursor" mode (in JAWS) needs to be used.
So, does that mean that all those keyboard shortcuts that users have
learned to navigate to the next heading, table, paragraph etc. are no
longer available?

If so, does the user now rely on the document author providing alternative
keyboard navigation. So, apart from hyperlinks and form controls which have
always allowed tab access/system focus, new techniques need to be included
for navigation such as up/down/right/left arrow keys and using the
"tabindex" attribute on most elements e.g. table, td, ul etc.

This is what I find "interesting" as we tackle web application
accessibility (versus web content).
HTML5 will help (as the browser will be able to natively describe more
controls (a calendar) and more attributes (such as a required field) to the
API. It's the potential movement away from the virtual buffer and greater
use of the live document that could be a challenge - for users and
developers.

phew...
Eamon


On Fri, Aug 6, 2010 at 12:33 PM, Alan M. Dalton <AMDalton at nda.ie> wrote:
  Hi Josh,

  (Sorry for interrupting your holidays!)

  Thanks for clarifying and explaining more about HTML5.

  I wonder if companies who make assistive technology are waiting to see
  how
  web developers use HTML5, before they decide how to implement it. After
  all, HTML5 is very new, and some of its elements might not become popular
  with web developers, and those elements might not appear on many
  websites.
  Some HTML 4.01 elements (such as abbr, cite, q, address, samp, and kbd)
  have been around for over a decade but have never been popular with web
  developers, and have appeared on very few websites. Assistive technology
  still has limited support for those elements.

  Maybe the only thing we can say for sure about HTML5's accessibility is
  that the safest way to use HTML5 is by including WAI-ARIA in it.

  Regards,
  Alan.
  _
  Alan Dalton
  Accessibility Development Advisor for EtA http://www.nda.ie/eta
  Access Officer for NDA http://www.nda.ie

  Address: National Disability Authority, 25 Clyde Road, Dublin 4.
  _



              Joshue O Connor
              <joshue.oconnor at n
              cbi.ie>                                                    To
              Sent by:                  Centre for Excellence in Universal
              ceud-ict-bounces@         Design ICT mailing list
              list.universaldes         <ceud-ict at list.universaldesign.ie>
              ign.ie                                                     cc
                                        "Alan M. Dalton" <AMDalton at nda.ie>
                                                                    Subject
              30/07/2010 22:00          Re: [CEUD-ICT] Accessibility of
                                        multiple main headings in HTML5
                                        webpages
              Please respond to
              joshue.oconnor at nc
                bi.ie; Please
                 respond to
                 Centre for
                Excellence in
              Universal Design
              ICT mailing list
              <ceud-ict at list.un
              iversaldesign.ie>






  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


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




  _______________________________________________
  CEUD-ICT mailing list
  CEUD-ICT at list.universaldesign.ie
  http://list.universaldesign.ie/mailman/listinfo/ceud-ict



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

  Is le haghaidh an duine nó an eintitis ar a bhfuil sí dírithe, agus le
  haghaidh an duine nó an eintitis sin amháin, a bheartaítear an fhaisnéis
  a tarchuireadh agus féadfaidh sé go bhfuil ábhar faoi rún agus/nó faoi
  phribhléid inti. Toirmisctear aon athbhreithniú, atarchur nó leathadh a
  dhéanamh ar an bhfaisnéis seo, aon úsáid eile a bhaint aisti nó aon
  ghníomh a dhéanamh ar a hiontaoibh, ag daoine nó ag eintitis seachas an
  faighteoir beartaithe. Má fuair tú é seo trí dhearmad, téigh i dteagmháil
  leis an seoltóir, le do thoil, agus scrios an t-ábhar as aon ríomhaire.
  Is é beartas na Roinne Dlí agus Cirt agus Athchóirithe Dlí na nOifígí
  agus na nGníomhaireachtaí a úsáideann seirbhísí TF na Roinne, seoladh
  ábhair cholúil a dhícheadú.
  Más rud é go measann tú gur ábhar colúil atá san ábhar atá sa
  teachtaireacht seo is ceart duit dul i dteagmháil leis an seoltóir
  láithreach agus le mailminder[ag]justice.ie chomh maith.

  The information transmitted is intended only for the person or entity to
  which it is addressed and may contain confidential and/or privileged
  material. Any review, retransmission, dissemination or other use of, or
  taking of any action in reliance upon, this information by persons or
  entities other than the intended recipient is prohibited. If you received
  this in error, please contact the sender and delete the material from any
  computer.  It is the policy of the Department of Justice and Law Reform
  and the Agencies and Offices using its IT services to disallow the
  sending of offensive material.
  Should you consider that the material contained in this message is
  offensive you should contact the sender immediately and also mailminder
  [at]justice.ie.
  **********************************************************************************



  _______________________________________________
  CEUD-ICT mailing list
  CEUD-ICT at list.universaldesign.ie
  http://list.universaldesign.ie/mailman/listinfo/ceud-ict
_______________________________________________
CEUD-ICT mailing list
CEUD-ICT at list.universaldesign.ie
http://list.universaldesign.ie/mailman/listinfo/ceud-ict