Add mappings for CSS display property.

[jcsteh]

🚀 Netlify Preview:
🔄 this PR updates the following sspecs:

• css-aam preview — css-aam diff

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	b064ff5
🔍 Latest deploy log	https://app.netlify.com/projects/wai-aria/deploys/6a7a996db532990008f7b3fc
😎 Deploy Preview	https://deploy-preview-2818--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

🚀 Deployed on https://deploy-preview-2818--wai-aria.netlify.app

[jcsteh]

From an editorial standpoint, I'm quite unsure of the right CSS classes, correct cross-referencing, etc. here.

[pkra]

If some ARIA spec language is desirable here, two existing options might be

• not hidden
• exposed

The latter doesn't appear to be referenced anywhere in the ARIA repository, so it could also be rephrased to fit here.

Otherwise, a new term might be usfeul

[jcsteh]

@pkra This is a bit of a tricky case because strictly speaking, display: contents has no impact on accessibility at all. There's no explicit mention anywhere that it should be excluded from the accessibility tree, which implicitly means that it should be included. The problem is that this is commonly misunderstood due to display: none, etc., so I think this should be explicit.

I think the best match in the ARIA spec is the concept of elements that must be included in the accessibility tree. However, that could be confusing because that section has a very explicit list of rules which doesn't have any allowance for extension via an AAM spec.

Alternatively, we could just say "not mapped" (since it doesn't map to any property in ARIA) and rely on the comments to make the tree inclusion explicit.

[jcsteh]

ARIA 7.1 Excluding Elements from the Accessibility Tree explicitly talks about host language semantics which exclude things from the tree. That leads to another possibility here: we could add text to ARIA 7.2 Including Elements in the Accessibility Tree; e.g.

Elements, including their descendent elements, that have host language semantics specifying that the element has explicit semantic relevance, such as CSS display:contents.

Yet another possibility is that we just link to the 7. Accessibility Tree section of the ARIA spec, which talks more generally about why something might be included in the accessibility tree (because it can fire events, has a feature which needs to be exposed, etc.).

[ZoeBijl]

Notes from the css-aam sync today:

• Reviewed PR Add mappings for CSS display property. #2818
• Should there be a definition for “Included” in ARIA?
• TODO: Correctly link to definitions and specs with ReSpec
• RESOLUTION: set maximum table of contents level to three.
• RESOLUTION: each property will have a generic “top” level (<h4>) with the various values nested inside (<h5>)

[ZoeBijl]

lgtm as discussed during review :)

[ZoeBijl]

We decided on having a generic top level for each property. Should we add some text here about the property? Maybe link to the relevant CSS spec that defines the property?

RESOLUTION: we decided to not include any text, less is more.