+++ CustomButtonNew.java 2016-12-13 14:51:30.000000000 -0200
@@ -749,7 +749,7 @@
if (!enabled) {
cleanupCaptureState();
Roles.getButtonRole().removeAriaPressedState(getElement());
- } else {
+ } else if (this instanceof ToggleButton) {
setAriaPressed(getCurrentFace());
}
}
@@ -925,7 +925,7 @@
setCurrentFaceElement(newFace.getFace());
addStyleDependentName(curFace.getName());
- if (isEnabled()) {
+ if (isEnabled() && this instanceof ToggleButton) {
setAriaPressed(newFace);
}
}
@@ -1102,4 +1102,3 @@
setCurrentFace(newFaceID);
}
}
-
On Tuesday, December 13, 2016 at 7:50:43 AM UTC-2, Thomas Broyer wrote:
On Tuesday, December 13, 2016 at 8:14:50 AM UTC+1, Julio Feferman wrote:I am instrumenting an application for best possible support for assistive technologies (ATs) such as screen readers, using GWT's ARIA implementation. I see that the CustomButton widget setEnabled() method sets the aria-pressed attribute on the button element if it is enabled. This is fine for a ToggleButton but wouldn't it be incorrect for a PushButton? When the aria-pressed attribute is present, screen readers interpret the widget as a toggle button. In the case of a push button, however, this attribute should not be present, in order to allow the AT to click the widget via keyboard commands, instead of toggling it.From the code, it looks like it sets the aria-pressed state to either true or false depending on the current pressed state when enabled, and un-sets the state when disabled.The thing is, a PushButton is CustomButton, which actually is a kind of "toggle button". The ToggleButton makes it easier to work with by adding style names corresponding to the "faces", providing constructors to easily create such "faces", and having a boolean value corresponding to the "pressed" state. And the PushButton is actually one such button that is only "pressed" while the mouse button or keyboard key is depressed.This seems to be in line with the WAI ARIA spec: https://www.w3.org/TR/wai-aria/states_and_properties# , with the exception that most people don't see a PushButton as such a "special kind of toggle button"; so I'd agree with you that aria-pressed shouldn't be used for a PushButton (leaky abstraction).aria-pressed Actually, I strongly believe CustomButton and derivatives are a legacy that should be avoided. They're from a time where you couldn't easily style <button>, or <input type=checkbox> to create toggle buttons; this is no longer the case.Don't use a PushButton, use a Button instead. And I'd even say don't use a ToggleButton, use a Checkbox (or RadioButton) with proper styling, and possibly add ARIA attributes to make it "appear" like a toggle button to ATs too.Even though I believe those widgets should be deprecated, feel free to propose a patch, I'll (help) review it. I'm not sure we could come up with a viable patch though: CustomButton is "too abstract", and yet we don't want to move the ARIA handling to subclasses as that would remove it from existing custom widgets people could have written based on CustomButton. Maybe add a boolean (add constructor overloads) telling the CustomButton whether it's a toggle button or a command button? (that seems slightly wrong though, as that'd mean the onClick/onClickStart/onClickCancel could probably use that information too instead of relying on subclasses to change the button's behavior). No, really, the long-term solution is to deprecate at least PushButton and move on to Button.
I agree that we should perhaps switch our uses of PushButton to a Button. However, I still believe ToggleButton is convenient for a series of use cases. For instance, a disclosure arrow that has an untoggled/toggled face (pointing right or down), in which case radio/checkbox are not appropriate. I'm submitting a patch here for CustomButton that inserts aria-pressed only in the case of (instanceof) a ToggleButton, completely removing the attribute for PushButton without interfering with the subclasses or current uses. The functionality would be preserved while only removing aria-pressed from PushButton. Thank you very much for your help.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment