- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 29 Nov 2010 07:06:39 +0800
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: HTMLWG WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby <rubys@intertwingly.net>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, "Michael(tm) Smith" <mike@w3.org>, Janina Sajka <janina@rednote.net>
- Message-ID: <AANLkTiku8fYAseiPe_A6-GbXVGHiK6H83UeasK4=mnde@mail.gmail.com>
Hi Ben, thanks for the detail. currently there are 5 main ways an AT user may access the content (output based on NVDA behaviour) 1. read all heading level 1 A problem solved heading level 2 Introduction Text for introduction section goes here heading level 3 Analysis heading level 2 The problem heading level 2 A mathematical model Text for problem section goes here heading level 2 Solution Text for problem section goes here. 2. line by line heading level 1 A problem solved heading level 2 Introduction Text for introduction section goes here heading level 3 Analysis heading level 2 The problem heading level 2 A mathematical model Text for problem section goes here heading level 2 Solution Text for problem section goes here. 3. heading by heading heading level 1 A problem solved Introduction heading level 2 Analysis heading level 3 The problem heading level 2 A mathematical model heading level 2 Solution heading level 2 4. heading list tree view - A problem solved - Introduction - Analysis - The problem - A mathematical model - Solution 5. naviagtion by heading level number (1-6) 1 heading level 1 A problem solved 2 Introduction heading level 2 The problem heading level 2 A mathematical model heading level 2 Solution heading level 2 3 Analysis heading level 3 Currently the HTML5 spec specifies how the heading list tree view should be calculated using the outline algorithm for: "For the purposes of document summaries, outlines, and the like, the text of hgroup elements is defined to be the text of the highest ranked h1–h6element descendant of the hgroup element, " http://dev.w3.org/html5/spec/sections.html#the-hgroup-element For the default display in a browser along with the rest of the content it does not define how headings should be treated. for all the other forms of in page navigation (1,2,3 and 5) what the roles and levels of the headings are is ambiguous (to me at least). I note in your first example, you have added 2 constructs "region" and "subtitle" that are not specified in the HTML5 outlining algorithm. Also in the second example the heading level 3 and 2nd heading level 2 in the hrgoup are treated as plain text, neither being a heading or a subtitle. so depending on the view (oultine or in page) the content of a hgroup (a) may be represented as either 1 or 2 (a) <hgroup> <h3>Analysis</h3> <h2>The problem</h2> <h2>A mathematical model</h2> </hgroup> 1. <h2>The problem</h2> 2. Analysis <h2>The problem</h2> A mathematical model In theory I don't have an issue with this, but it is not reflected in the current HTML% Spec as to acheive 1 the other headings in the hgroup would have to be treated as having CSS display:none or having the hidden attribute. To achieve 2 the h3 and 2nd h2 would have to be treated as having role=presentation. regards stevef On 28 November 2010 20:34, Benjamin Hawkes-Lewis < bhawkeslewis@googlemail.com> wrote: > On Sun, Nov 28, 2010 at 11:47 AM, Steve Faulkner > <faulkner.steve@gmail.com> wrote: > > I am not proposing that hgroup is ignored, I am suggesting that in the > > context of a user of AT moving through page content, as against accessing > > and naviagting via a page outline, the presence of the hgroup as a > heading > > does not make sense. > > These are certainly different scenarios, but ARIA/accessibility API > mappings might be used for both these scenarios. > > For example, a screen reader might list all the items in the > accessibility tree with "heading" roles, allowing the user to jump to > regions. If we map subtitles to headings then AT will not be able to > distinguish subtitles from headings when building such a list. > > > could you provide details of how your example should be conveyed to an AT > > user if they are using the cursor keys to move through content as against > > navigating via an outline? > > > > <h1>A problem solved</h1> > > <h2>Introduction</h2> > > <p>Text for introduction section goes here</p> > > <hgroup> > > <h3>Analysis</h3> > > <h2>The problem</h2> > > <h2>A mathematical model</h2> > > </hgroup> > > <p>Text for problem section goes here</p> > > <h2>Solution</h2> > > <p>Text for problem section goes here.</p> > > One possible verbose aural presentation would be as follows: > > New region > Heading level 1 A problem solved > New region > Heading level 2 Introduction > New region > Text for introduction section goes here. > New region > Subtitle Analysis > Heading level 2 The problem > Subtitle A mathematical model > Text for problem section goes here. > New region > Heading level 2 Solution > Text for problem section goes here. > > A less verbose presentation might be: > > Heading level 1 A problem solved > Heading level 2 Introduction > Text for introduction section goes here. > Analysis > Heading level 2 The problem > A mathematical model > Text for problem section goes here. > Heading level 2 Solution > Text for problem section goes here. > > I think the following would also be okay: > > Heading level 1 A problem solved > Heading level 2 Introduction > Text for introduction section goes here. > Heading level 2 > Analysis > The problem > A mathematical model > Text for problem section goes here. > Heading level 2 Solution > Text for problem section goes here. > > A disadvantage of this style is that if the user later used a heading > list accurately reflecting the document semantics defined by HTML5, > they might find it harder to locate the "hgroup" heading "The problem" > if they are listening for "Analysis". > > I don't think this presentational shorthand, where subtitles are > undistinguished, should be pushed right down to the API mapping level > as the Change Proposal currently suggests. > > > Also I thought that the oultine would be processed by the browser > rathert > > han handing it off to AT fior processing. > > The HTML5 outline algorithm yields an outline of the document structure. > > It can be used by any user agent that wants to present an outline of > the document structure. > > It makes sense to me that its outline of document structure would > match the outline implied by ARIA "region", "heading", and > "aria-level" mappings. > > If ATs build a different outline of the document structure based on > the accessibility API mapping, then the mapping has produced a > misrepresentation. > > -- > Benjamin Hawkes-Lewis > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 28 November 2010 23:07:33 UTC