Hi folks<br><br>My first post... Unfortunately it's a <i>very </i>long one, but hopefully it has a point :)<br><br>Another challenge that lies ahead is how screen reader users adapt to using WAI-ARIA.<br><br>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.<br>
However here's my understanding of how things stand, but by all means feel free to clarify any inaccuracies.<br><br>Most of us would have read and followed the techniques derived from the WCAG 1.0 guidelines (from circa. 1999).<br>
Since these were developed 11 years ago, they mainly focused on static "Web Content."<br><br>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.<br>
<br>What goes on "under the hood" is something like as follows:<br>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.<br>
The API passes this information to the screen reader.<br><br>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.<br>
<br>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".<br>
A virtual buffer is essentially a <i>snapshot</i> of a web page at a given point in time (often on page load).<br>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).<br>
<br>So why is a snapshot needed?<br>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.<br><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 10"><meta name="Originator" content="Microsoft Word 10"><link rel="File-List" href="file:///C:%5CUsers%5Ceamon%5CAppData%5CLocal%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml"><style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;
mso-font-charset:2;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:0 268435456 0 0 -2147483648 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";
mso-ansi-language:EN-US;
mso-fareast-language:EN-US;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:729697058;
mso-list-type:hybrid;
mso-list-template-ids:1412746768 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style=""><span style="font-size: 10pt; font-family: Arial;" lang="EN-US">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)</span></li><li class="MsoNormal" style=""><span style="font-size: 10pt; font-family: Arial;" lang="EN-US">It allows access to
static (normally) non-focusable text by simulating an insertion
point/caret.</span></li><li class="MsoNormal" style=""><span style="font-size: 10pt; font-family: Arial;" lang="EN-US"></span><span style="font-size: 10pt; font-family: Arial;" lang="EN-US">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.<br></span></li></ul><br>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.<br>
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.<br>
<br>However, <i>and this is what prompted my reply,</i> using WAI-ARIA requires the Screen Reader to avoid using a virtual buffer.<br>Instead the "PC Cursor" mode (in JAWS) needs to be used.<br>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? <br>
<br>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.<br>
<br>This is what I find "interesting" as we tackle web application accessibility (versus web content).<br>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.<br>
<br>phew...<br>Eamon<br><br><br><div class="gmail_quote">On Fri, Aug 6, 2010 at 12:33 PM, Alan M. Dalton <span dir="ltr"><<a href="mailto:AMDalton@nda.ie">AMDalton@nda.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Josh,<br>
<br>
(Sorry for interrupting your holidays!)<br>
<br>
Thanks for clarifying and explaining more about HTML5.<br>
<br>
I wonder if companies who make assistive technology are waiting to see how<br>
web developers use HTML5, before they decide how to implement it. After<br>
all, HTML5 is very new, and some of its elements might not become popular<br>
with web developers, and those elements might not appear on many websites.<br>
Some HTML 4.01 elements (such as abbr, cite, q, address, samp, and kbd)<br>
have been around for over a decade but have never been popular with web<br>
developers, and have appeared on very few websites. Assistive technology<br>
still has limited support for those elements.<br>
<br>
Maybe the only thing we can say for sure about HTML5's accessibility is<br>
that the safest way to use HTML5 is by including WAI-ARIA in it.<br>
<br>
Regards,<br>
Alan.<br>
_<br>
Alan Dalton<br>
Accessibility Development Advisor for EtA <a href="http://www.nda.ie/eta" target="_blank">http://www.nda.ie/eta</a><br>
Access Officer for NDA <a href="http://www.nda.ie" target="_blank">http://www.nda.ie</a><br>
<br>
Address: National Disability Authority, 25 Clyde Road, Dublin 4.<br>
_<br>
<br>
<br>
<br>
Joshue O Connor<br>
<joshue.oconnor@n<br>
<a href="http://cbi.ie" target="_blank">cbi.ie</a>> To<br>
Sent by: Centre for Excellence in Universal<br>
ceud-ict-bounces@ Design ICT mailing list<br>
list.universaldes <<a href="mailto:ceud-ict@list.universaldesign.ie">ceud-ict@list.universaldesign.ie</a>><br>
<a href="http://ign.ie" target="_blank">ign.ie</a> cc<br>
"Alan M. Dalton" <<a href="mailto:AMDalton@nda.ie">AMDalton@nda.ie</a>><br>
Subject<br>
30/07/2010 22:00 Re: [CEUD-ICT] Accessibility of<br>
<div class="im"> multiple main headings in HTML5<br>
webpages<br>
</div> Please respond to<br>
joshue.oconnor@nc<br>
<a href="http://bi.ie" target="_blank">bi.ie</a>; Please<br>
respond to<br>
Centre for<br>
Excellence in<br>
Universal Design<br>
ICT mailing list<br>
<ceud-ict@list.un<br>
<a href="http://iversaldesign.ie" target="_blank">iversaldesign.ie</a>><br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
Hi Alan,<br>
<br>
I am on hols at the moment, but I couldn't resist this one...<br>
<br>
> I'm wondering about multiple main headings in HTML5 webpages, and how<br>
> accessible they are for assistive technology users today.<br>
><br>
> The HTML5 specification allows a webpage to have multiple "article"<br>
> elements.<br>
<br>
The term 'article' should be understood to not just mean an 'article'<br>
(in terms of a newspaper article) but an 'item'. It denotes an object,<br>
item or part - with a high level of granularity. It can represent any<br>
discrete item.<br>
<br>
> Each "article" element can have a main heading, marked as <h1> in<br>
> the source code. A main heading in an article in an HTML5 webpage is only<br>
a<br>
> main heading for the content of that article; it is not a main heading<br>
for<br>
> content of the whole webpage. This is very different to the approach in<br>
> HTML 4.01 and XHTML 1.0, where each webpage typically has only one main<br>
> heading for all its content [1].<br>
<br>
Yes it is!<br>
<br>
> Having multiple "article" elements, each with its own main heading, seems<br>
> very practical. A lot of modern webpages (such as blogs) are basically a<br>
> collection of articles from various sources. With HTML5, a webpage author<br>
> can copy an entire article from somebody else's webpage, and paste it<br>
> directly into his own webpage, without having to worry about the<br>
structure<br>
> of his webpage.<br>
<br>
Yes [but]!! In accessibility terms VIP screen readers users are<br>
certainly used to the rather simple 'here is a HTML page with 1 <H1>,<br>
and several <H2>s etc' model. That's not going to be the way it works<br>
with HTML 5. The interesting thing is that I have no idea how AT vendors<br>
like Freedom Scientific will implement the spec in their product. Will<br>
the AT mediate the complexity brought on by /advances/ in the spec? Will<br>
users need to become more 'html aware' to navigate even rudimentary<br>
webcontent? These are very interesting questions that I look forward to<br>
finding out the answers to by practical testing :-)<br>
<br>
> Mark Pilgrim explains how to use multiple main headings in HTML5<br>
webpages,<br>
> in his "What Does It All Mean?" article [2]. He compares an XHTML 1.0<br>
> version of a weblog with an HTML5 version. Here's a simplified version of<br>
> his XHTML 1.0 version [3] :<br>
> <div><br>
> <h1>My Weblog</h1><br>
> </div><br>
> <div><br>
> <h2>Travel day</h2><br>
> <p>Lorem ipsum ... </p><br>
> </div><br>
> <div><br>
> <h2>I'm going to Prague!</h2><br>
> <p>Lorem ipsum ... </p><br>
> </div><br>
> Here's a simplified version of his HTML5 version [4] :<br>
> <header><br>
> <hgroup><br>
> <h1>My Weblog</h1><br>
> </hgroup><br>
> </header><br>
> <article><br>
> <header><br>
> <h1>Travel day</h1><br>
> </header><br>
> <p>Lorem ipsum ... </p><br>
> </article><br>
> <article><br>
> <header><br>
> <h1>I'm going to Prague!</h1><br>
> </header><br>
> <p>Lorem ipsum ... </p><br>
> </article><br>
><br>
> What do you think of the accessibility of this, considering the skills,<br>
> expectations, and software that assistive technology users have today?<br>
<br>
For a start the way users will interact with webcontent is going to<br>
change. We are used to browsing by headings, links etc. That will still<br>
be possible but there will be also be the ability to extract <article>,<br>
<aside>, <section>, <nav> elements and other attributes such as WAI<br>
ARIA, aria-describedby, aria-labelledby, ARIA LiveRegions etc.<br>
<br>
So I guess, users will be potentially able to extract <article> elements<br>
into a dialogue box rather like they do now, and then be able to<br>
navigate to any child content of the containing parent element. The same<br>
for the <section> element etc. FWIW, I do think there is going to be a<br>
lot of confusion of exactly /how/ to apply all of these elements. This<br>
can be expected in anytime of change and the good news is that the<br>
toolkit and its ability is expansive but again there is a wee learning<br>
curve yet to be dealt with!<br>
<br>
Part of the 'problem' is that HTML is no longer /just/ a declarative<br>
markup language but rather is is also a very sophisticated amalgam of<br>
APIs such as <canvas>, <video> etc. FWIW I wonder if there is just too<br>
much going on (there is a certain degree of duplication between elements<br>
and their functionality but again the spec is pretty explicit about how<br>
each element etc can be applied) but only time will tell how this will<br>
effect the end user.<br>
<br>
As I alluded to earlier the interesting issue for me is how AT vendors<br>
will implement HTML5 features. We have seen a wide uptake of parts of<br>
WAI-ARIA already in many of the main browsers, as well as in AT but as<br>
of yet I haven't seen much in terms of HTML 5 implementation. The spec<br>
proposes and the vendors dispose, so the spec is really just a document<br>
containing a series of recommendations/algorithms/behaviours/rules and<br>
their contexts and then the world decides to react or not.<br>
<br>
Anyway if it all goes Pete Tong, at least we have HTML 4 :-)<br>
<br>
My 2 cents<br>
<br>
Josh<br>
<br>
********************************************************************<br>
National Council for the Blind of Ireland (NCBI) is a company<br>
limited by guarantee (registered in Ireland No. 26293) .<br>
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.<br>
NCBI is also a registered Charity (chy4626).<br>
<br>
NOTICE: The information contained in this email and any attachments<br>
is confidential and may be privileged. If you are not the intended<br>
recipient you should not use, disclose, distribute or copy any of<br>
the content of it or of any attachment; you are requested to notify<br>
the sender immediately of your receipt of the email and then to<br>
delete it and any attachments from your system.<br>
<br>
NCBI endeavours to ensure that emails and any attachments generated<br>
by its staff are free from viruses or other contaminants. However,<br>
it cannot accept any responsibility for any such which are<br>
transmitted. We therefore recommend you scan all attachments.<br>
<br>
Please note that the statements and views expressed in this email<br>
and any attachments are those of the author and do not necessarily<br>
represent the views of NCBI<br>
<br>
<br>
********************************************************************<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
CEUD-ICT mailing list<br>
<a href="mailto:CEUD-ICT@list.universaldesign.ie">CEUD-ICT@list.universaldesign.ie</a><br>
<a href="http://list.universaldesign.ie/mailman/listinfo/ceud-ict" target="_blank">http://list.universaldesign.ie/mailman/listinfo/ceud-ict</a><br>
<br>
<br>
<br>
</div></div>**********************************************************************************<br>
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ú.<br>
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]<a href="http://justice.ie" target="_blank">justice.ie</a> chomh maith.<br>
<br>
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.<br>
Should you consider that the material contained in this message is offensive you should contact the sender immediately and also mailminder[at]<a href="http://justice.ie" target="_blank">justice.ie</a>.<br>
**********************************************************************************<br>
<div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
CEUD-ICT mailing list<br>
<a href="mailto:CEUD-ICT@list.universaldesign.ie">CEUD-ICT@list.universaldesign.ie</a><br>
<a href="http://list.universaldesign.ie/mailman/listinfo/ceud-ict" target="_blank">http://list.universaldesign.ie/mailman/listinfo/ceud-ict</a><br>
</div></div></blockquote></div><br>