-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Figure out what to do with the DPUB mappings overlap with the ARIA Core spec, in the context of newer implementation differences #1643
Comments
@aleventhal @joanmarie @mattgarrish @cyns @jnurthen @GeorgeKerscher @avneeshsingh @jcsteh @TzviyaSiegman @asurkov Apologies if I've overlooked anyone who is or was a stakeholder in these. |
Noting that I made a several revisions to the issue description above. They were mostly editorial (typos etc), but I've added a few specific notes (labeled "Update:") anywhere the errata/correction was more substantive. |
see w3c/dpub-aam#11 |
To add from the perspective of content production, after having been an early adopter of DPUB ARIA. While the DPUB ARIA roles were easy enough to implement, I've found the benefits of these roles for users to be quite limited. Of course, that's always a chicken and egg problem with AT providing affordances for new roles but after 5 years it feels like a good time check. From my recollection (and a quick test) both JAWS and NVDA mostly ignore the roles. When they don't, it's not clear if it's for the better. For example, NVDA adds elements with roles subclassing landmark to the landmark list; this makes sense but can get quite noisy. (The spec's suggestion to make footnotes I do think most of DPUB ARIA can be useful but maybe the information would work better as a sort of annotation of roles, a kind of "structured role description". Incidentally, I would find that particularly helpful for the link roles @cookiecrook criticized since this kind of link content can be very short and ambiguous (e.g., a footnote link or a bibliographic reference can just have To pick another example:
This is perhaps far-fetched but at least from real life: there's a US-based mathematics journal I work with which regularly publishes articles in French. I can easily imagine a non-English user following a DOI to such a paper from, say, another paper's reference list. Like most DOIs, this brings them to a page that includes the title and abstract in French - yet the rest of that page would be in English. Since the French equivalent for abstract would be résumé, even the heading content might not be a great help. Providing some form of structural information could help users here. Anyway, even after replacing English and French with less related languages, I admit this might not be the greatest example and I'm not arguing in favor of this particular role (or any DPUB role for that matter). I only mention it because I do think there's a lot of structural information in publishing workflows that users would benefit from if we found a way to make it available. In fact, there's far more than what's in DPUB ARIA (unsurprisingly, since DPUB ARIA mostly reproduces the older epub vocabulary). Looking forward to the deep dive. |
I think this statement could use some clarification first:
This wasn’t the motivation in bringing the roles into ARIA. That’s more of a history lesson in how EPUB’s That said, I think there’s always room for discussion about how roles should be exposed/announced. I’ve also been getting asked about this since we started publishing the DPUB-ARIA 1.1 drafts, but the mappings are not my area of expertise (as you’ll probably recall, Rich did most of the work creating the mappings document for us). Publishing is a big and messy space, so while you can find common naming patterns, they rarely hold up everywhere. Having a consistent set of semantics to identify the parts of a publication has been central to accessible publishing going back before EPUB to DAISY talking books. I expect you’ll find more openness on the publishing side to discussing the aspects of your proposal like what should be announced for roles rather than not having them announced at all or using their superclass roles to identify them. I can’t speak to why the difference exists, but I think I can safely say from discussion with folks on the publishing side that announcing the superclasses is viewed as the less helpful option, which is why they’re pushing to have the publishing names announced. My understanding from going through the 1.0 process is that the mappings are intended only to expose the roles, though. How they’re announced, and whether they’re announced, is for API and AT devs to determine, with users being able to customize their playback as well. You mentioned More to the point, I’m trying to understand if this is an issue that involves changes to DPUB-AAM, or if this is a question that is more general to the user experience. I opened the linked pull request in DPUB-AAM not expecting it will change the AX mappings, but because I was told the description fields are not necessary to specify anymore and are removed in ARIA 1.2. Is that correct in your view, @cookiecrook? I expect where we’re going to find the most agreement is in adding roles to ARIA core. I know we discussed having But this message is getting very long, so I'll cut myself off here. I expect @GeorgeKerscher, @avneeshsingh, @clapierre, @gregoriopellegrino and others will have more to say. |
Totally agree with what @mattgarrish wrote above. In terms of implementation our Global Certified Accessible (GCA) program which certifies publishers EPUBs as being accessible requires the use of DPUB ARIA roles be added to all relevant sections within the book. We have over a dozen publishers who have passed certification including some of the larger US publisher and the list is growing with an another dozen or more in the works to get fully certified. Not to mention our certification program is expanding where eBound Canada is using our program to certify Canadian publishers to also adopt the DPUB ARIA roles. For a list of publishers who have passed certification and are adding these roles to every EPUB coming off their production pipelines you can find that on our "Certified Publishers" webpage. Publishers are already including these roles in their EPUBs which are being published now, so that part of the chicken & egg problem is solved, the content is there now, so all we need is AT to expose this information in a user friendly and customizable way. As far as incorporating some of the DPUB aria roles into core, it depends on how it is implemented as I would not want to see those doc-* roles be dropped and instead be alias's to the core roles. I would not want to inform the publishers they have to say change their process for role="doc-chapter" to just role="chapter" but keep role="doc-acknowledgments" if that doesn't make it into core. So if there are aliases as Matt suggested then the author can use either this would fine. |
@clapierre wrote:
For compatibility reasons, I would not expect |
@mattgarrish wrote:
If I understand the question, I think whether there is a DPUB-AAM change depends on the outcome of the discussion. If we agree that there are a subset of DPUB roles that are unnecessary to explicitly convey to AT users via role description, then yes, I would expect DPUB-AAM to change to reflect that. But there would presumably be no DPUB-AAM change related to the ones that should should be brought into the Core ARIA spec, as with |
Thanks for the question @cookiecrook. @mattgarrish provides great background. I need a little time to think about this. Without giving this more than a few minutes thought, the most valuable roles to have spoken are chapter and subtitle. I would love to get feedback from people using AT. |
All of the roles are important when you're authoring the content. |
Right, my question is somewhat tangential to this thread in that the AXRoleDescription fields were all removed from the ARIA 1.2 specification and replaced with a note that says:
I don't believe those fields dictate what is to be announced, but I understand that is the perception of some for why the publishing roles are announced differently. I noticed the two new additions (doc-pageheader and doc-pagefooter) don't have an AXRoleDescription field, so I'm assuming it's safe to remove the others, but wanted to run it by you here since we're discussing this anyway. I'd like to merge that pull request but don't want to do something that will have to be undone by this issue. |
Discussed in ARIA WG - propose a meeting for a 9am pacific deep-dive on a Thursday in the new year? Please let me know your availability. |
Proposed date - Jan 13, 2022 - 9AM pacific (1700 UTC) |
That works for me.
…On Thu, Dec 2, 2021 at 2:17 PM James Nurthen ***@***.***> wrote:
Proposed date - Jan 13, 2022 - 9AM pacific (1700 UTC)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1643 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZSG76NXME4UBVTAIJTUO7A3ZANCNFSM5H3X32WQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
The proposed date works for the publishing folks I've talked to. |
great - I'll create the invite |
That's 3AM for me, so I unfortunately won't be able to attend.
I'm probably missing something here, but as far as I can see, Firefox doesn't expose any role descriptions for DPub roles on any platform. It exposes the semantic info (e.g. xml-roles for IA2), but not localised role descriptions. Are we talking about something else here? What am I missing? I see that the UIA mappings do recommend exposure of localised control types and localised landmark types. Firefox doesn't support UIA natively yet, so that isn't relevant to Firefox.
My personal opinion is that localised role descriptions should never be exposed for standardised roles. That's what we've upheld for IA2. This way, the AT can make the decision based on the semantic role and potentially other context. In contrast, if a role description is exposed, an AT has to report it; it can't reliably make any other decisions. Unfortunately, the UIA mappings have been defined such that this probably isn't an option now. |
@jcsteh wrote:
I may have misinterpreted some data from @GeorgeKerscher and @clapierre from their test results. There is a column called "inspector (Firefox on Windows)" that seems to indicate the "doc-*" roles are exposed, but in other columns, it does appear that the role descriptions are based on standard core ARIA parent roles. |
I agree with Jamie that the ideal is for the semantic role only to be exposed, and the AT to handle it. On ATK/IA2, this is what Chrome does, via the xml-role object attribute as suggested by Jamie. On Android and Mac, Chrome exposes a role description, because of the concern that it can take a long time for updates to those ATs to get into the hands of users -- admittedly a non-ideal shortcut. |
We're wandering into implementation differences here. Default role descriptions on Mac aren't typically provided by the AT because multiple Assistive Technologies use the same frameworks. If I understand Aaron, he's alluding to the fact that some core role descriptions are built into the system frameworks, including AppKit, but also WebKit. Native apps have always had the ability to override the framework-provided role descriptions or create custom ones. So IMO, it's reasonable to standardize the web role descriptions for DPUB, but the Rec should be a non-binding MAY (or an informative Note) to allow for small variants in platform UI and localization consistency. |
Looks like the role descriptions Chrome exposes on Mac for
DPUB-ARIA roles are incorrect, it's just the role string itself.
Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1277238
On Android, Chrome exposes the role description correctly.
|
Here are the roles I see as useful for Google Docs in the near term: |
I think doc-abstract, doc-endnote(s), doc-toc, and doc-subtitle are extremely valuable. I have not yet discussed with other members of Publishing. |
FWIW I also feel that the entirety of DPUB roles touches on broader topics that have come up on the calls in the last year or so (multiple roles, better descriptions for roles etc). I think this might be an opportunity to think a bit bigger than just the immediate problem of AX API mappings for DPUB roles. |
@cookiecrook I have inserted couple of more headings. Is it better now? |
"A non-print-disabled reader doesn't usually know the destination of a link before activating it. Do they?" @pkra has already explained it very well. |
@avneeshsingh wrote:
I'm still not certain how to move forward with the comments. Maybe you could confirm or deny my specific questions above? Here's one. @avneeshsingh wrote:
@cookiecrook replied:
This may be ideal because it'd allow e-readers, scripts, and AT the ability to offer additional user navigation (e.g. "Jump to Bibliography") to these structural elements, without penalizing the user with additional high verbosity: "Bibliography, bibliography group, heading level 2, Bibliography" |
Moving to 1.4 until getting relevant responses from DPUB. |
I'm going to move forward with a PR that exposes the programmatic platform roles (for example, as an AXSubrole on Mac) but without the verbose role descriptions on the disputed ones. This seems like it will allow the behavioral changes mentioned (and the braille embosser case @aleventhal mentioned) without adding extra verbosity. If people object on specific roles, I propose we raise those as individual issues. |
FYI this is on the ARIA agenda for TPAC. Currently scheduled for Friday morning, but I've asked @jnurthen to change it to Thursday to accommodate @avneeshsingh if he can attend remotely. @avneeshsingh Do you prefer morning or late afternoon Pacific time? |
Thanks @cookiecrook |
Had a good pre-meeting with @clapierre and Gregorio today and came to a good agreement I think. I have notes that I will try to summarize tomorrow before the Friday morning meeting. |
Trying to reconcile feedback with @clapierre and Gregorio from Wednesday with the prioritization notes from @avneeshsingh above. There are some conflicts in received information, so none of this is set in stone. Here are my rough thoughts to discuss in the group call Friday morning. Note, I may edit this more before that call. Consider as new Core Roles in ARIA main spec (in any case, map the doc-prefixed roles to AAM with new role/subrole and role description)
link roles:compromise: add role/subrole for these but keep role description "link" like the superclass role (prevents breaking user muscle memory)
Keep in DPUB, but need AAM role/subrole and role description:
Keep in DPUB: add subrole but keep the role description of the superclass (e.g. "group")Still question what utility this has to AT users... Make sure this doesn't end up as effectively EPUB API. (See also note below re: "group roles that keep superclass role description")
Others Avneesh listed above were not important to re-map in DPUB AAM (leave exposed as identical to the superclass role)... In hindsight I may have received conflicting info, so these may be undecided.
Questions (instances of conflicting info between Wednesday's discussion and the prioritization notes above, so I don't know where these will land)(Charles mentioned Wednesday he wanted to keep these; but Avneesh's WG prioritization list above indicates low importance)
Charles mentioned okay to skip, but above Avneesh ranked these higher.
Re: group roles that keep superclass role descriptionConsider: add subrole but keep role description matching that of the superclass role (e.g. "group")? Or maybe add something additional distinguishing information some non-intrusive, non-verbose way that is only available on demand. Still not sure how to do this, but thinking similar to Mac:AXListItem which is available for orientation but not spoken unless requested, or maybe something new like the "structured role description" @pkra mentioned above. |
re: |
Avneesh mentioned publishers want pagelist role or subrole... role description is still in open discussion. |
Random side note regarding the group of roles that are derived from link. The problem they try to solve seems related to the recent aria-link-target discussion (i.e., #1785) because those link roles, ultimately, try to inform users of the type of target they lead to (e.g., bibliographic reference, glossary/index, foot/endnote). I realize the aria-link-target discussion moved into a different direction but perhaps there is something to explore here. |
TPAC minutes: https://www.w3.org/2022/09/16-aria-minutes.html#t01 |
Some of the points in the minutes are hard to follow, but the takeaway Mac API proposal from TPAC was:
I'm floating this change proposal internally at Apple. |
Aforementioned "some API property" will likely use AXCustomContent, but waiting on specifics. |
WebKit tracker: https://webkit.org/b/248411 |
w3c/dpub-aam#15 is ready for review |
Figure out what to do with the DPUB mappings overlap with the ARIA Core spec, in the context of implementation differences.
Implementations of the DPUB Roles module are fragmenting based on some (recent?) implementation changes. In my opinion, the non AX API mappings in the DPUB ARIA Mapping are leading implementations to expose way too much cruft to the user.
For example, some Windows or Android AT users may now hear redundant ("appendix, appendix") or questionable ("qna") role descriptions. Even worse, some of these may be harmful to the understanding of the user interface. Do users know that the verbose "bibliographic reference" is actually a clickable link? [Update: previous "toc" example was updated to "qna" because based on test results, I'm not certain "toc" was ever spoken to a user.]
Background
When the DPUB working group published its ARIA roles module, the DPUB and ARIA groups met years ago and, as I recall, agreed to the following:
doc-acknowledgments
has a superclass role oflandmark
)biblioref
would be exposed as a regular "link" to screen reader users (similar to how sighted readers perceived it) but the EPUB renderer could cross-reference this element somewhere else in the UI.doc-chapter
should result in a newchapter
role for the ARIA spec. I don't think this last step ever happened. It may have been that the ARIA WG was focused on HTML Parity and de-scoped the DPUB convergence, or there may have been some other reason.Since that time, Firefox and Chrome have updated to expose the DPUB role descriptions mostly in line with the suggested screen reader output from DPUB (Microsoft Excel download).] @avneeshsingh and @GeorgeKerscher recently reached out to ask if Safari/WebKit would match the Chrome and Firefox implementations. While it would be a relatively simple technical change to do so, I think implementing the whole list would result in some unfortunate user interface changes, including aforementioned masked links, redundancy, and verbosity.
There are good and bad examples. For example, some Windows or Android AT users will now hear "chapter" on chapter roles (good) but the questionable ("qna") role description on a "Questions and Answers" container with a
doc-qna
role. Even if this latter role description was expanded in the implementation to the DPUB recommended "Questions and Answers" role description, it would be verbose and redundant, because the first element in most "doc-qna" sections is probably going to be a heading labeled "Frequently Asked Questions" or something similar. A user might hear "Questions and Answers, Frequently Asked Questions, heading." Some now hear, "qna, Frequently Asked Questions, heading." [Update: previous "toc" example was updated to "qna" because based on the DPUB test results, Talkback on Android does speak the "qna" role description. Also based on DPUB results, I'm not sure "toc" was ever spoken to a user.]More concerning are the link examples, where the role description potentially masks some interaction hint for the user. DPUB suggests the "doc-biblioref" role should expose a role description of "bibliography reference" so users may hear "bibliography reference, foo" instead of terse and predictable "link, foo." I doubt most users would immediately understand that "bibliography reference" means it's a clickable link, and even if they did, it increases the cognitive load for little or no user benefit. At default verbosity settings, there are eight syllables in "bibliographic reference" before a text-to-speech user would hear the contents of the link. I have the same concern for other link subclass roles such as
doc-noteref
anddoc-glossaryref
.DPUB Role Descriptions that should be Conveyed to Users of Assistive Technology, IMO
I'd first propose the DPUB and ARIA stakeholders agree on a list of role descriptions (including the non-controversial
chapter
role) that should be conveyed to users of assistive technology. WebKit could expose these to the AX API to match the other implementations.Optionally, the ARIA Working Group should whether consider that list (as a whole or individually) should be incorporated as core ARIA roles. DPUB's
doc-chapter
would then reference the new ARIAchapter
role as its superclass, rather than the more generallandmark
role. This would result in implementation changes to all engines, and would allow authors to userole="chapter"
rather than the more verbose and dpub-specificrole="doc-chapter"
.doc-backlink
may allow some interesting behavioral features (so the role itself should definitely be considered as a core role), though I'd argue that UIA's localized "backlink" may not be the right string to send to the user as a role description.DPUB Roles where the role description may NOT need to be conveyed to Users of Assistive Technology
I expect this may be a more controversial list, but I'll try to explain my thought process as a starting point. To be clear, I'm not suggesting that the roles not be exposed to the Accessibility APIs. They already are. Instead I'm suggesting that the AT end user (such as a screen reader user) doesn't need to hear about these differences. In the same vein, a sighted reader likely won't perceive any visual difference between these sections or types of elements.
Certain container role descriptions are redundant to convey to users.
I just picked up 5 or 6 print books off my desk and bookshelf. In all cases where these sections were available, the results were consistent.
In the one book that had Author Notes, the title was "A Note About the Author"[Update: This example may be irrelevant. DPUB has adoc-endnotes
role but not adoc-authornotes
role.]Certain other non-container DPUB role descriptions are unnecessary to convey to users.
There was not an "abstract" section in any of the books I picked up, but I think it's similar to colophon, in that the context is clear, regardless of whether the publisher chooses to visibly include a title labeled "Abstract." If the publisher doesn't choose to burden a sighted users with an unnecessary title, why would we want to subject screen reader users to one in the form of a role description?
To reference an existing core role description, "list item" usually isn't spoken by AT because doing so would be annoying, so there is practically no difference whether the engines send longer localized strings for more specific list item subclasses to the API or not, since each would be a subclass of listitem. I don't have a strong preference, but we typically wouldn't make an academic code change that results in no functional or perceptual user benefit.
I don't recall ever seeing a "dedication" labeled with a title, but the context is always clear. Why would a screen reader user want to hear "dedication, For my daughter" or "For my daughter, dedication" when the content "For my daughter" is immediately clear on its own?
This is an incomplete list, but I'm hopeful it's shows why WebKit engineers did not choose to convey most of these role descriptions to end users. (Honestly, I'm surprised that Chromium and Gecko engineers didn't question these mappings at the time. There may be a great reason that I missed.) In any case, I think it's enough to start the discussion and I look forward to learning from you all.
The text was updated successfully, but these errors were encountered: