nvda
nvda copied to clipboard
nvaccess
ARIA Flowto regions are not announced or traversable in Browse Mode
Reported by bgaraventa on 2014-04-03 18:24 An ARIA Flowto region is defined when aria-flowto is set to a specific ID reference to flow to.
When an ID points to another aria-flowto declaration, it creates a chain to link related non-contiguous regions together, so that the user has the choice of traversing via the arrow keys in the normal reading order, or by skipping forward and backwards through the flowto regions using a special hotkey.
For example, when using the latest version of JAWS in Firefox, a region that is marked with aria-flowto is announced as "has flowTo", and a target region that is pointed to with a valid ID is announced as "has flowFrom". When a container is both a target region as well as an aria-flowto region pointing to another ID on the page, it is announced as "has flowFrom has flowTo", indicating both options when arrowing in the Virtual Buffer. It is then possible to press the Equals key (=) to jump forward from one flowto region to another within the chain, or to press Shift+= to jump backwards within the chain.
When viewing a page that contains aria-flowto regions in NVDA however, it is not possible to identify where they are nor is it possible to traverse the chain.
Steps to reproduce:
- Open the attached html page.
- Attempt to identify which regions are flowto regions.
- Attempt to navigate the chain of flowto regions.
- Confirm that steps 2 and 3 are impossible.
Attachment index.html added by bgaraventa on 2014-04-03 18:29 Description: ARIA Flowto demo Update: File added from Trac index.html.txt
Comment 2 by Wildebrew on 2015-06-10 12:42 Any update on this ticket/enhancement request? This feature would be by far the easiest way to enable screen reader users to "glance at" foot notes (legal disclaimers/terms and conditions) on websites. I frequently deal with issues on large corporate websites, where significant development time is spent on creating in-page links to serve same purpose. Without creating two such links for every foot note reference (one to get to the foot note, one to get back to user's previous location) that does not even create a good user experience for screen reader users. Without broader screen reader support however, it is impossible to make that recommendation.
@bgaraventa, @Wildebrew what is the advantage of aria-flowto regions compared to landmarks? In NVDA you can navigate with m or d from landmark to landmark of from region to region in browse mode. I see that this navigation is already very efficient on complex corporate websites, I am working in financial modelling domain and have alot to do with big statistical databases in Internet. Landmarks and regions seem to be common practice for those websites like EIU, Worldbank etc. But maybe you have more experience with this.
aria-flowto is basically a way to rearrange the order of the content on the webpage for screen readers.
The only browser/screen reader combo that implements aria-flowto (as far as I know), is Jaws with Firefox. When you hit an element with an aria-flowto attribute, you can press = to navigate from that element to the target element and shift-= to navigate back from the target to the element with the attribute.
This is useful when you have information that users may want to read sequentially but is not displayed sequentially on the page, e.g. from a footnotes reference to a foot note or a total price of something etc. Yes, you could just link the two, but sometimes you hvae multiple references to a single footnote and it can require a lot of Javascript to make that work properly.
An ARIA landmark is a way to break a web page into standard sections and (optionally) give those sections accessible names (screen reader labels). Users can navigate to those sections from anywhere, but marking them as lnadmarks does not rearrange the order in which they are presented by a screen reader.
I would use aria-flowto on small blocks of content, not on engire landmark regions. I can see people arguing that there is very limited use case for this attribute, though I've seen a few situations where I think it could be super helpful. But if screen reader vendors think there is limited use case for this I want them to push back on the ARIA working group (i.e. by filing GitHub issues) and request this attribute be dropped (in W3C terms I guess we call it depricated). The problem I am seeing with the ARIA spec is that it doesn't really care whether an attribute is supported or not, and it goes for quantity over quality. However, in order to conform to WCAG, your code must not only be sematnically correct but must have assistive technology support, in at least one popular combination of browser/assistive technology, so to it is important that when you use something, be it HTML or ARIA, that the something you are coding has basic support. We don't need more attributes and roles nd complexities, we need more support and agreement on how to implement and support ARIA.
On 5/23/19, Adriani90 [email protected] wrote:
@bgaraventa, @Wildebrew what is the advantage of aria-flowto regions compared to landmarks? In NVDA you can navigate with m or d from landmark to landmark of from region to region in browse mode. I see that this navigation is already very efficient on complex corporate websites, I am working in financial modelling domain and have alot to do with big statistical databases in Internet. Landmarks and regions seem to be common practice for those websites like EIU, Worldbank etc. But maybe you have more experience with this.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/4049#issuecomment-495372573
-- Work hard. Have fun. Make history.
@Wildebrew I am with you regarding Support fo atributes in ARIA in General. Well, before requesting the deprecation of an atribute, I would like to see some other opinions on this from developers and users. cc: @michaelDCurran, @jcsteh, @josephsl, @stevefaulkner maybe you have additional arguments on this?
In General, I think we should really try to Support as many atributes as possible in the Screen Readers because this is the only way to make sure that most Websites work properly for the users. Some use landmarks, some use aria-flowto and so on. Having all them supported, just minimizes accessibility issues reported by users in General. But regarding the Need of an atribute, this will be really hard to assess because we will never be able to know exactly which atributes are commonly used and which not. There are far too many Websites out there and this is a different perspective compared to third Party apps or Software Solutions. Moreover, corporates are seeing the Need for accessibility more and more and they will put work on implementing accessible Solutions professionally.
Bot one Thing we should not Forget, the more atributes we use, the more verbose a Website can be for an user. So if we want efficient Navigation, we should also think about how to verbose those atributes. But this is a different issue.
I have updated the initial description with a link that explains this attribute in more depth: https://www.w3.org/WAI/GL/wiki/Using_aria-flowto To summarise my interpretation; "flowto" can allow for an optional, tree-like alternative to tab order.
Though at the moment I'm not sure if I know enough about this attribute to have an opinion, it looks like "flowto" has a long history.
There also needs to be push from web developers who need a feature like "flowto" to be able to provide experiences they wish to.
I also support the need for this feature.
In addition to the practical use case stated in https://github.com/nvaccess/nvda/issues/4049#issuecomment-155319276, when teaching web developers to adhere to WCAG and test with NVDA, we somewhat loose their conviction when having to deal with "well, not all of WCAG, because NVDA does not fully implement ARIA".
Use case: Branching flowcharts. They are typically browseable, rather than operable content. They are not at all unusual or exotic. But there is no sufficient technique, or even an advisory technique for making flowcharts accessible right now.
The only way to get an implementation working at the moment is to put each choice box 'step' in the tab sequence, and navigate to it with the tab key, which raises expectation about operable content (and is the only way to stop ATs like NVDA intercepting the keyboard events, which might handle the switch). Authors must then handle skipping focus themselves with javaScript. I've had content fail an audit because my flowchart boxes have a tabindex, but are not 'really' operable.
Now, the 'correct sequence' in a flowchart is the one that applies to the particular sub-case that a given path through the flowchart addresses, which might not be the sequence in the markup order. When reading a flowchart with branches, one of the sequences will always be correct, and the others will always be incorrect.
Consider a lifesaving algorithm. An early 'choice box' in the algorithm might be "Is the patient breathing?" (Yes/No) or "Does the patient have a pulse?" (Yes/No) The correct sequence - the only really 'meaningful sequence' is the one that matches the patient's condition. We certainly can not rely on the source order. WCAG's requirement that "Only one correct order needs to be provided" is absolutely insufficient here for communicating the germane content. It would be plain wrong to follow the "patient has a pulse" branch, if the patient doesn't actually have a pulse. It is therefore pretty much impossible to get a flowchart to comply with SC 1.3.2. without compromising the meaning.
So, what's really needed is to establish some idiom for choosing between the 'next' elements specified in the value of the aria-flowto attribute. This is sorely lacking, and makes aria-flowto pretty much useless in the real world.
It's very likely that any viable technique would draw upon the WAI-ARIA Graphics module (SVG, rather than HTML). But a HTML use case could be imagined too.
I suggest that if an element with flowto comes into focus (virtual focus, or operable focus), ATs should (at the very least) announce that fact. They should also announce how many branches it has (rather like announcing how many items appear in a list).
If the value of flowto contains only one id, then maybe it need not announce how many branches it has, and the 'jump' to that element should not require a choice step. In such a case, it might usefully omit mention of the presence of a flowto relationship.
It should be up to the content author to make sure that the 'pathways' between the non-source-adjacent elements are explicit (e.g. represented on screen with arrows or whatever), so that any 'jumping about' the document happens within expectations, and does not disorient the sighted user.
So, once browsed-to, there should be a key to cycle through the elements whose ids appear in the flowto attribute. JAWS made a stab at this, using the + key, but does nothing interesting with it. NVDA could announce some informative flowto-related prefix, perhaps followed by the accessible name. "Flow to 1 of 2: Patient has a pulse" (press + key) "Flow to 2 of 2: Patient has no pulse"... where "Patient has a pulse" and "Patient has no pulse" are perhaps the accessible names (aria-labels?) of the elements in question. (I'd prefer if the outgoing branches from a flowto element could be labeled independently of the 'destinations', but that's a matter for the ARIA guys).
The default branch should (I suppose) be the one whose id appears first in the aria-flowto value.
After choosing a branch, or accepting the default one, if you then press down-arrow NVDA should browse to the relevant element, regardless of whatever is next in the source order (i.e. the virtual/'reading cursor' should 'jump').
How does this sound?
If using Tab (rather than browse mode) to navigate the flow, tabbing off the choice box should focus() the appropriate 'selected' element from the flowto value. This behavior can already be scripted with current technology, but again, it may be inappropriate or misleading to use operable idioms for essentially non-operable content.
So, aria-flowto should be also supported for browseable content, not just operable content, which puts the ball firmly in the court of the AT developers. NVDA could and should take the lead here.
So... practically speaking, what keystroke would be appropriate for making a choice of branch? Not sure if + is so great, because it is hidden behind a modifier on some keyboards (e.g. German), but I'll take whatever I can get.
Colibrio Publishing specifically requested aria-flowto support in a tweet, (to us and others): https://twitter.com/ColibrioReader/status/1488087574224719876
"In other #Inkscape news, I'm currently argumenting for a UI to add #aria roles to elements "Ok hand" @NVAccess, @googleaccess, @AppleSupport, @MSFTEnable how about adding aria-flowto support? We want accessible rich layout publications"
Another use-case: highlighted text in a document (like Google Docs) that is connected to a comment box floating to the side. I've been searching for a way to link these two things, and flowto sounds like the most applicable! It works in JAWS but not NVDA.
Google Docs implements their entire system using canvases, so I'm not able to just copy what they do.
@oliver-byteboard A better fit for this use case is probably Aria Annotations (specifically aria-details)
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Annotations
This is still a work-in-progress.
Currently, the summary of an aria-details target can be reported (while at the source) with NVDA+d
Navigating to annotations is under development, once a comfortable UX has been developed for this, it could be applied to aria-flowTo
Aria-details issues:
- https://github.com/nvaccess/nvda/issues/13795
- https://github.com/nvaccess/nvda/issues/13940
@feerrenrut That would be perfect too! I am also waiting on #13940 because aria-details would be wonderful. Right now JAWS supports aria-flowto and voiceover supports neither, so we are looking for a solution in the meantime. Big thanks to the folks contributing to NVDA!
I'm throwing my weight behind aria-flowto.
I think aria-details is just grand, but it's clearly intended for a different use case. Also the aria-details spec as currently drafted does not address any of the problems that make aria-flowto unviable today. It's a solution to a different problem.
Please, NVDA devs, help us keep aria-flowto alive until we have ironed out its flaws.
Important:
Even if aria-flowto gets deprecated, and we have to rely on aria-details for handling its prime use case, then offering a way to choose from among the flow targets still needs to happen.
Has anyone imagined how NVDA might do that? Can we discuss it here?