Consider creation of aria-textattribute property for role parity with generic

[joanmarie]

We have quite a few generic-role candidates related to formatting that is relevant to the user -- not sufficiently relevant to justify a dedicated role, but still something we may wish to preserve and expose to users through their assistive technologies. In order to expose this formatting, we could have an attribute such as aria-textattribute (namesmithing welcome :smile: ).

My current thought is that aria-textattribute would have the value of token. It would only be supported on the to-be-created "generic" role. And it would contain one of the following values:

• abbreviation
• address
• bold
• italic
• keyboard
• mark
• preformatted
• quote
• strikethrough
• sample
• small
• underline
• variable

Thoughts?

[carmacleod]

I think it needs to be a space-separated token list, because it is possible to have "bold italic underline", etc.

[joanmarie]

So given <b><i><u>foo</u></i></b>, we'd just have one generic element?

[jnurthen]

So given <b><i><u>foo</u></i></b>, we'd just have one generic element?

Wouldn't that be better?

[joanmarie]

Not sure. I'm just asking. :)

[joanmarie]

Straw poll 1 of 2: We want an attribute.

[carmacleod]

See also @aleventhal's: https://github.com/w3c/html-aam/issues/551

[joanmarie]

Straw poll 2: We want to make it a space-separated token list.

[css-meeting-bot]

The ARIA Working Group just discussed text attributes.

The full IRC log of that discussion

<mck> TOPIC: text attributes
<joanie> https://github.com/w3c/aria/issues/960
<jamesn> GitHub: https://github.com/w3c/aria/issues/960
<mck> Proposal for an aria-textattribute property.
<mck> Mostly for generic roles.
<joanie> abbreviation
<joanie> address
<joanie> bold
<joanie> italic
<joanie> keyboard
<joanie> mark
<joanie> preformatted
<joanie> quote
<joanie> strikethrough
<joanie> sample
<joanie> small
<joanie> underline
<joanie> variable
<mck> Except for abbr and address, these are all about what text looks like
<mck> In attempt to reduce number of attribs needed, included those two.
<mck> Do we want na attrib to expose this formatting stuff?
<mck> gg: what is the alternative?
<jamesn> straw poll do we want an attribute to expose at least one of these?
<mck> jd: They do not get exposed, exposed through existing platform API text font or format, which would not happen in canvas, for instance.
<jamesn> +1
<joanie> +1
<HarrisSchneiderman> +1
<carmacleod> +1
<Glen> +1
<CurtBellew> +1
<melanierichards> +1
<jongund> +1
<mck> +1
<joanie> So given <b><i><u>foo</u></i></b>, we'd just have one generic element?
<mck> gg: do not want a generic role where the text run has different attributes on each char in the run
<mck> jd: let's say it is a single attrib run.
<mck> +1
<jamesn> straw poll 2: is text attribute a space seperated token list (+1) or a single string (-1)
<jamesn> +1
<Glen> +1
<HarrisSchneiderman> +1
<joanie> +1
<jongund> 0
<carmacleod> +1
<CurtBellew> +1

[brennanyoung]

Is the point of this attribute is to express semantics, or is it to allow presentational tags to 'flavor' the content reported by the AT?

I'd rather see parity for the true semantic inline tags such as <strong> and <em> than for <b> and <i>!

Re. the IRC log, "Except for abbr and address, these are all about what text looks like".

I disagree, strikethrough expresses a very distinct semantic, which has a radical effect on the meaning. It's not just presentation. The same applies (perhaps less radically) to mark, quote, keyboard, sample and var. A quote is definitely not a presentational thing, and if AT users are not informed that something is a quote, it may be mistakenly attributed to the document's own author. Not desirable.

[jnurthen]

@brennanyoung ARIA 1.2 already includes the following roles strong , emphasis, insertion, deletion and blockquote mark is already in the editors draft for 1.3 to support the annotations work.

[jnurthen]

Are we still considering this or should we close?

[scottaohara]

i was under the impression this wasn't really needed anymore with the way that generic has panned out in implementations.