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

[Joshue O Connor]

Hi Eamon,

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

Yes, but this is the issue with any technical specification and not just
WAI-ARIA. This is probably less of an issue due to progress with
WAI-ARIA adoption into HTML 5 and there has been a lot a progress in
terms of vendor implementation (by both browser makers and AT
companies). Some posts etc that may be of interest.. some background,
the screen reader shoot out, adoption in IE8 and toolkits like YUI. [1]
[2] [3] [4] [5]

> 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.

Well, that is partially true but a major limitation that you missed here
is within the languages themselves. There just were no rich descriptive
semantics for widgets etc that devs were building using <divs>,
scripting and CSS - so ARIA is a perfect bridging technology. The bridge
being towards HTML5, with its host of APIs etc however, there are some
things that ARIA does well now in existing browsers, and the code is
ignored by those that don't support it.. while we wait(ed) for HTML5..
so its win-win.

HTML 4 etc were primarily document markup languages and now the web has
a huge amount of rich content that needs to be described so people with
disabilities can understand what it is and interact with it. HTML5 will
do a lot to help this, but understanding the context of where ARIA came
from, (out of the DHTML roadmap, while HTML5 looked like vapourware a
while back :-\) [6]


> 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.

If this information has been added (hence the need for semantically
'correct' or just proper markup).

> The API passes this information to the screen reader.

Yes. This is often done via the virtual buffer, or OSM and directly.

> 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.

Yes.

> 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).

Yes.

> 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).

It is the default when browsing the web, but is not needed for desktop
browsing due to tighter integration between AT and the OS, and also that
the identity of elements has already been programmatically determined at
the OS level.


> 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 can be yes, this can lead to a disconnect between what had focus in
the browser and what the screen reader user 'sees'. In particular for
asynchronous content like AJAX etc.

>    - 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.

Yes, but only if the good structured code exists in the first place,
that the AT can get a hold on.

> 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. 

See above.

> And this is the problem that ARIA is hoping to solve, in a very
> intelligent way I might add.

That is only a part of it really, and in fact the situation that you
outline was kinda fixed with the increases in virtual buffer updating
times. The user did often have to update the virtual buffer manually to
refresh the screen reader snapshot of the page content, but that changed
circa JAWS 8 IIRC as the time of virtual buffer updates was shortened to
only several milliseconds, and it meant that the virtual buffer and was
pretty in sync with what was happening onscreen. There was a slight
delay but things did lastly improve.

The right honourable Gez Lemon and myself wrote a paper on this very
issue many moons ago. [7]

ARIA is mainly enabling devs to add useful semantics to RIAs where the
limitations in the host language just won't cut the mustard. So you can
made accessible sliders, tree widgets, grids etc. So it really is like a
Swiss army knife of accessibility!

All of this stuff can be plugged into the host language like HTML, but
it could just as easily be another like SVG.

> 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?

Good question, yes. This is not perfect. Hence, for example the notion
of role="application" to enable PC Cursor mode and then interaction ARIA
enabled content. This is to make the widgets etc that have this role
applied behave more like desktop applications.  Ideally the user should
just be able to interact with the content (whether HTML 5 and/or ARIA)
and while this will improve the kind of thing that you mention is a
concern.  [8]

Not all ARIA functionality needs these kind of mode changes however. If
supported an ARIA enabled widget will often have its role just be
announced by the AT without this kind of mode shift so, the features
users have enjoyed using the Virtual buffer can still be used.

The complexity should be mediated by the tech, and not the user.

> If so, does the user now rely on the document author providing alternative
> keyboard navigation. 

Well, for example with role="application" care should be taken that all
functionality is accessible via the keyboard.

> 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.

Note, that the use of 'tabindex' etc to provide focus is a hack (a
necessary one but a hack nonetheless), the hope is that HTML5 etc will
allow the kind of expanded UI features that you are talking about.

> 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.

+1. Good post Eamon!!

Cheers

Josh

[1] http://www.cfit.ie/news-and-commentary-archive/96-wai-aria-in-html5
[2] http://www.paciellogroup.com/blog/?p=585
[3]
http://www.marcozehe.de/2009/07/01/the-wai-aria-windows-screen-reader-shootout/
[4]
http://www.456bereastreet.com/archive/200902/wai-aria_support_in_ie8_rc_no_longer_non-standard/
[5] http://yuiblog.com/blog/2008/10/02/yui-aria/
[6] http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap040506.html
[7] http://www.axmedis.org/axmedis2006/program.html
[8]
http://terrillthompson.blogspot.com/2009/11/musings-on-aria-roleapplication.html








********************************************************************
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


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