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
ARIA tab panels should be handled consistently inside and outside of the virtual buffer #709
Comments
Comment 2 by jteh on 2010-06-16 22:59 I think I understand your use case, but implementing it would break a lot of other cases. I'm not keen on specific exceptions for tab panels. We need to come up with a good rule here. |
Comment 3 by vtsaran (in reply to comment 2) on 2010-06-17 04:43
|
Comment 4 by jteh (in reply to comment 3) on 2010-06-17 05:10
To answer this, let me address another of your questions:
It's more correct to say that when in browse mode, all navigation reads using browse mode logic. So, quick navigation and tabbing read in exactly the same way.
How do sighted users know which tab panel they are in? Do they just determine this by looking to see which is the selected tab or is there some other heading somewhere? How is the situation different for screen reader users? Let's use this ticket editing form as an example. It has a fieldset with a legend of "Change Properties", which is similar to a property page in that it is a container for controls. NVDA doesn't read this while navigating in the virtual buffer because the legend itself is already part of the buffer and is right above the text. Otherwise, when pressing down arrow, you would hear "Change Properties" as you hit the legend, then "Change Properties grouping" as you moved down into the fieldset. |
Comment 5 by vtsaran (in reply to comment 4) on 2010-06-17 07:28
Well, the selected tab is one aspect of it. vertical Alignment is another. The third one is ability to see how the content changes in response to the tab selection with a click. There also may be coloring, but I am not sure of that. Screen reader users do not have that luxury because the content is represented in a linear fashion inside the virtual buffer. Another thing to remember is that sighted users rarely have a need to tab inside the content pane unless they want to interact with elements inside it. Screen reader users do not have that choice. Ideally, the beginning and the end of tab panel, as well as other DHTML widgets, should be announced but this is beyond the scope of this ticket.
Well, I understand the rationale for the arrow keys, but I was expecting the TAB key to interact with the browser directly, hence was my suggestion. Feel free to close this ticket if you don't think my suggestion goes against NVDA's philosophy. |
Comment 6 by jteh on 2010-06-17 07:32 One possibility is to make an exception for property pages, since they're rather unique in some ways. They would then be read as a container in the buffer like lists, tables, landmarks, etc., except that the name would be read as well. I'm not quite sure how this could be done yet, nor am I sure if it is the best solution. |
I wonder whether it would help if we'd treat tabs as landmarks. Thus, announce the tab when you cursor in it, and announce "out of tab" when you cursor out of it. |
I'm sorry to enter this call. |
Fixing #3321 should make this get reported when tabbing. The open question is whether the property page should be read when reading with the arrow keys, etc. We don't want to do that for groupings because groupings normally have a heading and that would result in duplication. Arguably, tab panels don't have a heading beyond the selected tab itself, which isn't quite as clear. P3 to at least consider the UX here. |
Could someone please provide exact steps to reproduce it? On yahoo.com I cannot reproduce it. But the website has been redesigned. |
STR:
Now that #3321 has been fixed (via #7435), this bug is trivial to fix. Just check for controlTypes.ROLE_PROPERTYPAGE as well as ROLE_GROUPING at around line 178 of source/speech.py. |
This commit fixes nvaccess#709 by expanding the check introduced in nvaccess#3321 for property pages.
Reported by vtsaran on 2010-06-16 06:38
On the yahoo.com page there are at least two ARIA tab panels, one listing the search categories and another one listing the news categories (right after the "news" heading). In both instances there is an additional HTML link between the list of tabs and the content pane for a particular tab. For example, in the "search categories" tab panel there is a "more" link followed by a content pane containing the edit field and the "search" button. At the same time the "news" tab panel contains a "move to top" or "move news down" link between the list of tabs and the content pane for a particular tab. In both instances the aria-labelledby property is used to link the list of tabs with the content pane.
When inside a virtual buffer NVDA does not establish the contextual link between the list of tabs and the content pane by saying "xyz property page", however, it does so without a problem when the user is in "focus mode". It could be the case that the link in between disorients NVDA or that the panel is not coded correctly, but then NVDA's behavior should be consistent for both "browse" and "focus" modes.
I believe aria-labelledby property should provide enough context for NVDA to associate the list of tabs with the content pane even if they do not follow each other in the tab order.
The text was updated successfully, but these errors were encountered: