After listening to the Google IO web components presentation I decided to take another look at this emerging web technology. It sort of struck me as a client side version of server side includes. Anyway I was interested in testing out an experimental implementation of web components in Chrome and to see how it plays with ARIA.
what are web components?
I am making no attempt at explaining what it is, as I would probably make a hash of it, but here is how web components is described in the Introduction to Web Components document:
The component model for the Web (also known as Web Components) consists of four pieces designed to be used together to let web application authors define widgets with a level of visual richness not possible with CSS alone, and ease of composition and reuse not possible with script libraries today.
How does use of the shadow DOM content affect ARIA use?
A potential sticking point about web components from an accessibility standpoint is that the HTML inserted into a document using web components is included in the Shadow DOM not the regular HTML DOM. I wanted to check how this affects the use of ARIA roles, states and properties.
Initial findings
Results from initial testing indicate that inclusion of ARIA roles,
states and properties in content wholly inside the Shadow DOM works
fine. The accessibility information is exposed correctly via the
accessibility API. Screen readers can access content in the Shadow DOM
without issue. There is a problem however if ARIA relationship
attributes such as aria-labelledby are used on content in
the regular DOM that references content in the Shadow DOM or, used on
content in the shadow DOM that references content in the regular DOM.
So if an input is in the shadow DOM:
<input type="text" aria-labelledby="light">
references an element in the regular DOM
<span id="light">regular label for text box in shadow</span>
The expected result i.e. the accessible name for the input is the text content of the referenced element, does not happen. The labelledby relationship is broken.
Detailed tests and results page
Notes:
These are only initial tests and findings based on my limited understanding of web components and experimental implementations.
To only view the results any browser will do
To test, or view content in the shadow DOM you will need:
- Chrome with the shadow DOM experimental feature enabled.
- To enable, put
chrome://flagsin the address bar and open the flags page. - Enable the “Shadow DOM. Mac, Windows, Linux, Chrome OS This API allows web applications to use Web Components.” flag.
- Also useful to enable “Developer Tools experiments. Mac, Windows, Linux, Chrome OS Enable Developer Tools experiments. Use Settings panel in Developer Tools to toggle individual experiments.” flag so you can see Shadow DOM content in the developer tools. Note you have to check “show shadow DOM” in the developer tools setting as well.
- an accessibility information inspection tool such as aViewer
