This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
David, do you mind if I steal this one?
(In reply to comment #1) > David, do you mind if I steal this one? Completely fell of my radar. Please do!
Created attachment 1382 [details] wip Is it ok to take this as a pattern?
(In reply to comment #3) > Created attachment 1382 [details] > wip > > Is it ok to take this as a pattern? I think the additions are helpful, though we'll want to be consistent and add the new classes and markup as applicable in the MSAA + UIA Express, MSAA + IA2, and AT-SPI columns as well, so there is a bit of work to do in that regard. The other concern I have is about using CSS generated content to add meaningful content that isn't already provided some other way. CSS generated content is not well supported for various browser/screen readers, nor is it best practice. What about adding the "Role: ", "States: ", "Actions: ", etc. text directly as content? It's an unpleasant task, but no more unpleasant than adding the markup as proposed in the patch.
(In reply to comment #4) > (In reply to comment #3) > > Created attachment 1382 [details] > > wip > > > > Is it ok to take this as a pattern? > > I think the additions are helpful, though we'll want to be consistent and > add the new classes and markup as applicable in the MSAA + UIA Express, MSAA > + IA2, and AT-SPI columns as well, so there is a bit of work to do in that > regard. I will handle IA2 + ATK. > The other concern I have is about using CSS generated content to add > meaningful content that isn't already provided some other way. CSS generated > content is not well supported for various browser/screen readers, nor is it > best practice. > What about adding the "Role: ", "States: ", "Actions: ", etc. text directly > as content? It's an unpleasant task, but no more unpleasant than adding the > markup as proposed in the patch. fine with me
(In reply to comment #5) > I will handle IA2 + ATK. I'll take UIA Express and UIA then. I'm assuming the best terminology will be "Control Type", and "Control Pattern" as applicable. Where there are Text Attribute Identifiers or Property Identifiers, perhaps just "Identifier" will be sufficient, otherwise it's getting a little verbose. But since they're rather few in number, being more explicit might be better. Will take a stab and see how it goes.
Can you give a code snippet please how you think the things should look to make sure we are on the same page?
The content of table cells is currently laid out mostly with <br> elements. There are a few <p>s in there. What do you think about the following options? <td> <span class="type">Role: </span>ROLE_SYSTEM_LINK<br><br> <span class="type">States: </span>STATE_SYSTEM_LINKED to link and all its descendants. If link is visited then STATE_SYSTEM_TRAVERSED.<br><br> <span class="type">Actions: </span>"jump" action on link and all its descendants. </td> <td> <b>Role:</b> ROLE_SYSTEM_LINK<br><br> <b>States:</b> STATE_SYSTEM_LINKED to link and all its descendants. If link is visited then STATE_SYSTEM_TRAVERSED.<br><br> <b>Actions:</b> "jump" action on link and all its descendants. </td> I think I'm partial to the second one.
the first one is more flexible since we can apply CSS styles. Should we have a class for the whole item like <div class="item"> <span class="type">Role: </span>IA2_ROLE_SHAPE </div> also we might want to have specific classes like "role", "states" instead generic "item", that'd be helpful if we want to have some automatic processing in the future or just for simple findings in the source code. btw, 4 spaces looks like a really huge offset (I've got usual to deal with 2 spaces offset)
(In reply to comment #9) > the first one is more flexible since we can apply CSS styles. Should we have > a class for the whole item like > > <div class="item"> > <span class="type">Role: </span>IA2_ROLE_SHAPE > </div> > > also we might want to have specific classes like "role", "states" instead > generic "item", that'd be helpful if we want to have some automatic > processing in the future or just for simple findings in the source code. > Agree. It involves more work in preparing for the heartbeat, assuming that we want to commit to having these changes implemented for the heartbeat. > btw, 4 spaces looks like a really huge offset (I've got usual to deal with 2 > spaces offset) That's gonna be a personal preference, but I've no objections if you want to change it.
(In reply to comment #10) > (In reply to comment #9) > > the first one is more flexible since we can apply CSS styles. Should we have > > a class for the whole item like > > > > <div class="item"> > > <span class="type">Role: </span>IA2_ROLE_SHAPE > > </div> > > > > also we might want to have specific classes like "role", "states" instead > > generic "item", that'd be helpful if we want to have some automatic > > processing in the future or just for simple findings in the source code. > > > > Agree. It involves more work in preparing for the heartbeat, assuming that > we want to commit to having these changes implemented for the heartbeat. I can go with either way. The major work for me is to check implementation, different specs, write some tests. Fixing a HTML spec is a minor work with me. > > btw, 4 spaces looks like a really huge offset (I've got usual to deal with 2 > > spaces offset) > > That's gonna be a personal preference, but I've no objections if you want to > change it. I'd go with 2 spaces, otherwise noticeable portion of the screen is in spaces for me :)
Created attachment 1383 [details] wip2 next version, please check if it looks ok
(In reply to comment #12) > Created attachment 1383 [details] > wip2 > > next version, please check if it looks ok Works for me.
Created attachment 1384 [details] IA2 A-D v1 let's go by parts (please check if it looks ok before I land it)
(In reply to comment #14) > Created attachment 1384 [details] > IA2 A-D v1 > > let's go by parts (please check if it looks ok before I land it) Looks good. Just wondering if its worth considering some shorter class names, e.g., .general -> .gen .objattrs -> .objatt .textattrs -> .txtatt .relations -> .rel Either way, okay by me to land it.
I'd go with longer names, especially because it's mostly copy/paste thing
Alex, I just noticed that for those elements where MSAA doesn't provide a distinct role, you've indicated use of BSTR to pass the tag name as role string. As I understand it, this is a browser-specific approach to overcome the limits of MSAA and is considered non-conformant with the MSAA spec. Last September it was decided that we wouldn't include browser-specific notes in the normative mappings, but that the more common of these alternative approaches would be described in the "Other Accessibility Implementations" section of the mapping guide [1]. The string in VARIANT approach is described in this section [2]. This followed from a bug you filed regarding the blockquote and q mappings [3]. What do you think about adding the BSTR notes to section 5.1 instead and describing in more detail the use of BSTR, maybe listing there which elements get that treatment? Also, it seems that Mozilla is considering or close to removing the BSTR hack? [4] [1] http://rawgithub.com/w3c/html-api-map/master/index.html#other-accessibility-implementations [2] http://rawgithub.com/w3c/html-api-map/master/index.html#use-of-msaa-variant-by-some-user-agents [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16769#c3 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=798492
(In reply to comment #17) > Alex, I just noticed that for those elements where MSAA doesn't provide a > distinct role, you've indicated use of BSTR to pass the tag name as role > string. As I understand it, this is a browser-specific approach to overcome > the limits of MSAA and is considered non-conformant with the MSAA spec. As you know there are two implementations: IE and Firefox (Chrome). As long as we have two columns MSAA + UI Express and MSAA + IA2 then we put alternative implementations right into the table. In other words as long as MSAA columns of the same row contain different values then we deal with alternative implementations because the browser simply can't provide two MSAA implementations. > Last September it was decided that we wouldn't include browser-specific > notes in the normative mappings, but that the more common of these > alternative approaches would be described in the "Other Accessibility > Implementations" section of the mapping guide [1]. The string in VARIANT > approach is described in this section [2]. This followed from a bug you > filed regarding the blockquote and q mappings [3]. I think I can remove those but what should I put there instead of it? Does it make sense to point there some generic role even if nobody implements it? > What do you think about adding the BSTR notes to section 5.1 instead and > describing in more detail the use of BSTR, maybe listing there which > elements get that treatment? We can do this but basically it should mean that we need to copy/paste that big table, right? > Also, it seems that Mozilla is considering or close to removing the BSTR > hack? [4] only for ARIA roles, iirc AT have dependencies on tag name BSTR roles.
Let's I finish the mapping using BSTR roles in this bug for now and let's have another follow up where we decide how we will proceed with it. Sounds ok?
A-D elements: https://github.com/w3c/html-api-map/commit/7f8297c08db06eab8abecf619a14c6a60c5ce5f2 E-F elements: https://github.com/w3c/html-api-map/commit/dfb2e75bf7efa1373af94772e6eccdfe6f263d00
H-I elements: https://github.com/w3c/html-api-map/commit/b1408c7e1dea01e49ebedebce56f7cbb7969ee64
(In reply to comment #18) > (In reply to comment #17) > > Alex, I just noticed that for those elements where MSAA doesn't provide a > > distinct role, you've indicated use of BSTR to pass the tag name as role > > string. As I understand it, this is a browser-specific approach to overcome > > the limits of MSAA and is considered non-conformant with the MSAA spec. > > As you know there are two implementations: IE and Firefox (Chrome). As long > as we have two columns MSAA + UI Express and MSAA + IA2 then we put > alternative implementations right into the table. In other words as long as > MSAA columns of the same row contain different values then we deal with > alternative implementations because the browser simply can't provide two > MSAA implementations. > > > Last September it was decided that we wouldn't include browser-specific > > notes in the normative mappings, but that the more common of these > > alternative approaches would be described in the "Other Accessibility > > Implementations" section of the mapping guide [1]. The string in VARIANT > > approach is described in this section [2]. This followed from a bug you > > filed regarding the blockquote and q mappings [3]. > > I think I can remove those but what should I put there instead of it? Does > it make sense to point there some generic role even if nobody implements it? As far as I know, the intention is for the mapping guide to be a normative spec, in which case I'm not sure we want to be using the mapping tables to document browser-specific uses of a11y APIs, esp. where they don't conform to the API's spec. If a generic role is appropriate, but nobody currently implements it, then we can point to that role in the table, but note in section 5.1 the alternative approaches that other UAs take. > > > What do you think about adding the BSTR notes to section 5.1 instead and > > describing in more detail the use of BSTR, maybe listing there which > > elements get that treatment? > > We can do this but basically it should mean that we need to copy/paste that > big table, right? Instead of a table, couldn't we add some text similar to that on the MDN site? https://developer.mozilla.org/en-US/docs/Accessibility/AT-APIs/Differences/MSAA#_Document_Structure_Exposed_in_MSAA_Tree_
(In reply to comment #19) > Let's I finish the mapping using BSTR roles in this bug for now and let's > have another follow up where we decide how we will proceed with it. Sounds > ok? I'd prefer to have it sorted in time for the heartbeat, given previous discussions/decisions on what the mapping tables represent. But I'm not opposed to reopening the discussion either, so to that extent, as long as what we have for the heartbeat is at least temporarily coherent, I'm fine with leaving the BSTRs in the mappings for now. The doc is in a lot of flux recently, and I expect this to keep up post heartbeat, so there's not that much of an issue either way.
(In reply to comment #22) > As far as I know, the intention is for the mapping guide to be a normative > spec, in which case I'm not sure we want to be using the mapping tables to > document browser-specific uses of a11y APIs, esp. where they don't conform > to the API's spec. Do I understand right it means that MSAA+UIExpress and MSAA+IA2 must have same values for MSAA parts? > If a generic role is appropriate, but nobody currently > implements it, then we can point to that role in the table, but note in > section 5.1 the alternative approaches that other UAs take. what mark can be used to specify this is "should be" (not "must be") item? > Instead of a table, couldn't we add some text similar to that on the MDN > site? > https://developer.mozilla.org/en-US/docs/Accessibility/AT-APIs/Differences/ > MSAA#_Document_Structure_Exposed_in_MSAA_Tree_ btw, do the spec really needs to describe alternative implementations?
(In reply to comment #24) > Do I understand right it means that MSAA+UIExpress and MSAA+IA2 must have > same values for MSAA parts? That's how I understand it. Compare the ARIA UA Implementation table: http://www.w3.org/TR/wai-aria-implementation/#mapping_role_table > > If a generic role is appropriate, but nobody currently > > implements it, then we can point to that role in the table, but note in > > section 5.1 the alternative approaches that other UAs take. > > what mark can be used to specify this is "should be" (not "must be") item? > I'm proposing that the entries in the mapping table make no reference to the BSTR (or other) approaches, and that these be dealt with entirely in section 5.1. For example, with some text such as the following: "In Firefox, the following HTML elements are exposed using the tag name as a BSTR values in the VARIANT: abbr, acronym, blockquote, dd, dl, dt, form, frame, h1, h2, h3, h4, h5, h6, iframe, q, tbody, tfoot, thead..." [Adding to the list as necessary] > > Instead of a table, couldn't we add some text similar to that on the MDN > > site? > > https://developer.mozilla.org/en-US/docs/Accessibility/AT-APIs/Differences/ > > MSAA#_Document_Structure_Exposed_in_MSAA_Tree_ > > btw, do the spec really needs to describe alternative implementations? I'm considering the use of BSTR an alternative implementation, and given its extensive use by Firefox and Chrome, I think it's worth describing, just not part of the normative mappings. Again, I'm not opposed to reopening this decision. Would be great to get Cynthia and Steve's comments.
(In reply to comment #25) > (In reply to comment #24) > > > Do I understand right it means that MSAA+UIExpress and MSAA+IA2 must have > > same values for MSAA parts? > That's how I understand it. Compare the ARIA UA Implementation table: > http://www.w3.org/TR/wai-aria-implementation/#mapping_role_table ok, that makes sense but then we probably should have 3 columns: MSAA, UIA Express and IAccessible2. Otherwise it's confusing because the single implementation can't maintain two different MSAA implementation (one is for UIA Express and another one for IA2). What do you think?
Btw, if MSAA impl is supposed to be same then how do we manage when UIA Express claims a certain role and IA2 says there's no accessible?
Looking more it seems MSAA mapping is too different in UIAExpress and IA2 columns to have a common multiplier. It seems like the whole IA2 column can be treated as alternative implementation to UIAExpress.
(In reply to comment #28) > Looking more it seems MSAA mapping is too different in UIAExpress and IA2 > columns to have a common multiplier. It seems like the whole IA2 column can > be treated as alternative implementation to UIAExpress. The MSAA+UIAExpress column needs to be updated so that the MSAA role guidance matches that as you have it in the MSAA+IA2 column, particularly for those elements where there is no accessible, ie, where MSAA+UIAExpress currently suggests ROLE_SYSTEM_TEXT. That was a mistake, I think, from a while back. I need to take care of that, and quick! But if that change is done, then I think things should be clearer (and consistent with the way the ARIA mappings are presented, unless you think the way the ARIA mappings are presented isn't clear).
Ok, I need to finish the mapping and then we can make sure MSAA implementation can be shared between UIAExpress and IA2. IA2 K-N elements: https://github.com/w3c/html-api-map/commit/5555f5c7084e5a940416be1d393d594c900e456a
O-R elements: https://github.com/w3c/html-api-map/commit/eaef32f395ebc8099ab1e55ee9e56b3103947990
S-W elements (IA2): https://github.com/w3c/html-api-map/commit/8170d9e8e60fb9db5a2b3ff1bcf6327c1cb76ebd
ATK A-I elements: https://github.com/w3c/html-api-map/commit/9b5845373ee0442d0b7829d612cabe9810a86331
Where an element doesn't have an accessible, but is exposed via text attributes, could "Role: None" be used to indicate this in a way that's more consistent with the presentation of mappings for other elements? The use of text attributes could then be added in <div class="general"></div>. What do you think?
(In reply to comment #34) > Where an element doesn't have an accessible, but is exposed via text > attributes, could "Role: None" be used to indicate this in a way that's more > consistent with the presentation of mappings for other elements? > The use of > text attributes could then be added in <div class="general"></div>. What do > you think? I wouldn't do this. Having a role implies there's an accessible. Especially there are rare cases when the accessible may have unknown role which is sort of close to role:none.
ATK K-W elements: https://github.com/w3c/html-api-map/commit/227e554e1b746d0aa012d8fe63ec26429902bb25