[WebPayments] The buttons inside a row are not navigable |
||||
Issue descriptionThe buttons inside a row (e.g., choose/add on the summary screen, or edit pencils on the address lists) are not navigable using VoiceOver. This navigation does seem to be possible using Windows screen readers, so this is likely a VoiceOver-specific issue. Inspecting these elements with the Accessibility Inspector doesn't reveal anything peculiar about them. One fix attempted was changing the AXRole of their parents from Button to Group, but all that accomplished was making the entire row unclickable, with no change to the navigability of their children. Impact: - VO users can't navigate to sheets which aren't populated with a default selection, because the rows themselves are considered disabled elements (with only the blue button inside enabled) - VO users can't edit complete profiles/payment methods. They *can* modify profiles/payments if they have errors, since clicking on these rows (as if to select them ) instead opens the editor screen.
,
Jul 17 2017
+tapted, +patricialor, +dmazzoni for some MacViews and a11y insight. Re: the Mac issue in c#1, we have a Button, styled as a clickable row in a list, and a Button inside that row. For some reason, VO never traverses the inner Button. In Accessibility Inspector I see the inner button listed under the Row's children, and the Row listed as the Button's parent, and both of them are visible. Can you think of any other factors that would affect traversability this way?
,
Jul 18 2017
voiceover probably objects to having a button-within-a-button. "entering" a button with VO+shift+down lets you interact with the button title only - not other subviews of the button. I suspect you don't need nesting here. E.g. make the edit button a sibling of the payment method button that gets drawn after it/on top of it. A container NSView may help with layout.
,
Dec 9 2017
Hello, I'm looking to sort this bug as to whether or not it is a Windows bug. I saw a mention that "This navigation does seem to be possible using Windows screen readers" but there are repro details on Windows. The JAWS behavior is different from the NVDA behavior. Is this bug cross-platform or specific to VoiceOver? Should the JAWS/NVDA discrepancy be filed into its own bug? Thanks, Laura
,
Dec 15 2017
,
Mar 1 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by tmartino@chromium.org
, Jul 14 2017