need role for sub and sup #877
Comments
|
It came up at last year's face-to-face that we might wish to apply the generic role for these two elements and use some to-be-determined property for the formatting. We should discuss this. |
|
One reason for an attribute rather than a role (in my mind) is whether or not there is semantic meaning we want to preserve through a role. The HTML spec says the following about
It also says:
|
|
Maybe a generic with Regarding "aria-typography" or "aria-style" or whatever we call it (some kind of attribute describing "presentational semantics"), maybe we need to look at the other generics as well so that we can see the whole picture. |
|
Consensus from meeting: We're going to expose these as roles. |
|
The ARIA Working Group just discussed The full IRC log of that discussion<jamesn> Topic: Sub and Sup<jamesn> github: https://github.com//issues/877 <MarkMcCarthy> joanie: sup and sup were originally identified as needing their own roles, leaning towards that <MarkMcCarthy> ... mck suggested maybe we could use the generic role <MarkMcCarthy> joanie: what I put, before carmacleod commented, are thoughts on why we want a role, in particular if there's semantic meaning <joanie> These elements must be used only to mark up typographical conventions with specific meanings, not for typographical presentation for presentation’s sake. For example, it would be inappropriate for the `sub` and `sup` elements to be used in the name of the LaTeX document preparation system. In general, authors should use these elements only if the _absence_ of those elements would change the meaning of the <joanie> content. <pkra> pfffft <MarkMcCarthy> carmacleod: Sure. It'd be interesting to have an attribute on that new role as well, as you've opened the other bug. <MarkMcCarthy> ... I was thinking if we put it as a generic, there's an option to have another attribute as well as context <MarkMcCarthy> ... I called it aria-typography, but that's completely a draft name <joanie> q+ to disagree <MarkMcCarthy> ... reason being, the other genric roles we've talked about, all those almost fit in the same area. I just want to look at the bigger picture first <MarkMcCarthy> ... these are sort of the same idea? if we throw thwem all into the same attribute that specifies "presentational semantics" maybe that's good enough? <MarkMcCarthy> q+ mck <jamesn> q+ Matt <jamesn> q- Matt <MarkMcCarthy> joanie: I raised the point I did since I am a screen reader developer <MarkMcCarthy> ... and the generic role might be everywhere. for sup/sup, we might want to announce them differently than the others <MarkMcCarthy> ... what carmacleod is describing is essentially asking to check every generic role for what it's content is <MarkMcCarthy> ... what might be funny with mapping is that the way it might be exposed might be different <MarkMcCarthy> ... aria-typography might be better for something like CSS <MarkMcCarthy> carmacleod: I didn't know your platform has it in the API <pkra> q+ <MarkMcCarthy> ack joanie <Zakim> joanie, you wanted to disagree <joanie> ack me <MarkMcCarthy> ack mck <MarkMcCarthy> mck: as long as I can remember, we've had this discussion role vs. property <MarkMcCarthy> ... there's a whole lot of HTML that by default does some styling to communicate a semantic, like bold vs. strong, headings, etc. <MarkMcCarthy> ... these individual decisions about aria-attribute vs. role seems like a discussion where we don't have many principles, except what joanie mentioned about platforms <MarkMcCarthy> ... we don't have consistency across the board with accessibility APIs <MarkMcCarthy> ... if anyone can come to the table with cohesive principles, that'd be hepful. I don't see it. <joanie> q+ To say the principle is that if an AT can ignore it and the user experience doesn't change, it's generic <MarkMcCarthy> ack pkra <MarkMcCarthy> pkra: the spec description for sup/sup seems weird. wisest choice might be to say do what HTML does <MarkMcCarthy> pkra: doesn't seem wise to go beyond what they're giving, esp as this is parity <joanie> ack me <Zakim> joanie, you wanted to say the principle is that if an AT can ignore it and the user experience doesn't change, it's generic <MarkMcCarthy> joanie: if an AT can ignore and UX doesn't change, it's generic <MarkMcCarthy> ... user needs to know about headings, for instance. for sup/sup, X2 vs X sub 2 or X sup 2 is different <MarkMcCarthy> mck: if reading a text, and you say "all boldface text means XYZ," then there's meaning with bold text that screen readers don't know <joanie> q+ to say strong versus bold elements <MarkMcCarthy> ... reader may want to choose to have bold read differently <MarkMcCarthy> ... could argue this is true about headings as well <joanie> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong <joanie> q? <joanie> ack me <Zakim> joanie, you wanted to say strong versus bold elements <MarkMcCarthy> ... we might want to mimic HTML, which might not be best but defendable <MarkMcCarthy> joanie: I hear you mck, but HTML for better or worse has bold and strong. sometimes authors need guidance <MarkMcCarthy> ... authors should use b tag if it's not semantically important, strong if it is <MarkMcCarthy> ... so I'd like b to be generic, ideally, and strong not generic, so screen readers present items differently <pkra> q+ <MarkMcCarthy> mck: do DPUB folks have something to say? <MarkMcCarthy> jamesn: no one here today <MarkMcCarthy> ack pkra <MarkMcCarthy> pkra: I don't know why use case isn't mentioned, but there's obvious use of subscript, like chemistry etc. <MarkMcCarthy> jamesn: we'll have annotations <MarkMcCarthy> pkra: though I suppose you find footnote -scripts in MathML too <MarkMcCarthy> jamesn: are we near a conclusion? many opinions. I'm leaning towards that if it's on a platform API then go for it <MarkMcCarthy> carmacleod: +1 <MarkMcCarthy> joanie: yes, but not all APIs have the same things <MarkMcCarthy> jamesn: it should be an indicator to us that if it's in a platform API and we decide it's not semantic, that'd be a mistake <MarkMcCarthy> mck: what we don't tell screen reader devs is that you always announce roles and sometimes properties - that's not our job <MarkMcCarthy> joanie: right, i didn't say that <MarkMcCarthy> joanie: concensus is what? <MarkMcCarthy> jamesn: expose as roles? <MarkMcCarthy> carmacleod: yes, i'm okay with that. I can see the screen readers POV now <pkra> +1 for roles <MarkMcCarthy> mck: maybe for the generic case, it's generally the browser's responsibility to take care of element attributes? <MarkMcCarthy> jamesn: let's talk about that when we come back to generic <MarkMcCarthy> mck: let's go forward with roles <MarkMcCarthy> [no disagreements] <MarkMcCarthy> JamesCraig: thanks for discussing generic, it's important to me <MarkMcCarthy> zakim, take up item 5 <Zakim> agendum 5. "Issue 867: add draft specification for role label" taken up [from jamesn] |
|
can this issue be closed since #904 was merged? |
|
Yes. It was left open because at the time we weren't using the wiki to track remaining stuff. Thanks for the ping. |
per plans for role parity need a role for equivalent to
<sub>and<sup>in HTMLThe text was updated successfully, but these errors were encountered: