New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 365070 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All , Chrome
Pri: 2
Type: Bug

Sign in to add a comment

expose (heading) level in acc layer based on heading elements outline depth

Project Member Reported by, Apr 19 2014

Issue description

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:

and browser extensions:


related User Agent Accessibility Guideline criteria
Provide alternative views
This bug came about from a lengthy Twitter conversion trying to work out why the w3 HTML spec recommends against nested sections (a note Steve added).

Got to the root of the issue eventually -, we're exposing the wrong heading level to ATs.


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.

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

Acc API mappings

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

Object attributes:  level:<heading_level> 
Interfaces:  AtkText; AtkHypertext  

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
Labels: OS-Chrome
Labels: Needs-Investigation
Status: Available (was: Untriaged)
@David for input on whether or not this is still relevant 

Sign in to add a comment