New issue
Advanced search Search tips
Starred by 5 users
Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment
expose (heading) level in acc layer based on heading elements outline depth
Project Member Reported by faulkner...@gmail.com, Apr 19 2014 Back to list
Currently the HTML5 outline algorithm [1] is not implemented, I propose implementing and exposing as a DOM method (document.outline()) so developers and 3rd part software such as assistive technology can provide a document outline to users. 

The HTML5 outline algorithm is implemented in conformance checkers:
http://validator.w3.org/nu/ 
https://github.com/validator/

and browser extensions:
https://chrome.google.com/webstore/detail/html5-outliner/afoibpobokebhgfnknfndkgemglggomo?hl=en

[1] http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines

 
related User Agent Accessibility Guideline criteria
Provide alternative views
http://www.w3.org/TR/UAAG20/#gl-alternative-views
This bug came about from a lengthy Twitter conversion trying to work out why the w3 HTML spec recommends against nested sections http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines (a note Steve added).

Got to the root of the issue eventually - https://twitter.com/stevefaulkner/status/457451517436784640, we're exposing the wrong heading level to ATs.

Example: http://jsbin.com/yuyay/1/quiet

Currently we're giving the heading an AXValue (in OSX) of 1, 1, 2. It should be 1, 2, 3 according to the HTML outline algorithm. http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outlines

Fixing this should be of immediate benefit to ATs.

Recommend repurposing this ticket for fixing the heading level issue, the DOM API proposal in the OP is a distraction. 
Labels: -Type-Feature Type-Bug
Summary: expose (heading) level in acc layer based on heading elements outline depth (was: expose output of html5 outline algorithm as a DOM method)
i.e. implement 'heading role, with the aria-level property set to the element's outline depth' as per  
http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics

Acc API mappings
http://rawgit.com/w3c/html-api-map/master/index.html#el-h1-h6

* MSAA + IAccessible2 *
Role:  IA2_ROLE_HEADING 
Object attributes:  level:<heading_level> 
Interfaces:  IAccessibleText2; IAccessibleHypertext2; 

*ATK*
Role:  ATK_ROLE_HEADING 
Object attributes:  level:<heading_level> 
Interfaces:  AtkText; AtkHypertext  

*AX*
AXRole: AXHeading 
AXSubrole: (nil) 
AXRoleDescription: "heading" 
Properties: Use AXLevel to expose the heading level
"the DOM API proposal in the OP is a distraction."

I think while dom api proposal is wider in scope, I don't think it should be classed as a distraction.

Not all screen readers access the acc tree exposed via acc APIs, as I understand it chromevox is JS/DOm based, so exposing via MSAA/Ia2/STK/Ax acc APIs only, does not provide the ability for DOM based tools such as chromevox to access the output of a document outline exposed in the acc layer only.

Also not all OS's have acc API's as I understand it, Chrome OS for example, does not.

Providing a DOM API to access the doc outline would mean that any AT could access it as well as mainstream software and developers. 
Labels: -Cr-Blink
Labels: NewComponent-Accessibility NewComponent-Accessibility-ChromeVox
Components: UI>Accessibility>ChromeVox
Labels: -newcomponent-accessibility -newcomponent-accessibility-chromevox
Components: -UI>Accessibility
Sign in to add a comment