[Webkit-unassigned] [Bug 98357] [GTK] accessibility/aria-readonly.html is failing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=98357





--- Comment #3 from chris fleizach <cfleizach at apple.com>  2012-12-10 09:24:27 PST ---
(In reply to comment #1)
> Created an attachment (id=178569)
 --> (https://bugs.webkit.org/attachment.cgi?id=178569&action=review) [details]
> test case for discussion
> 
> While working on this bug, I came across the following issue: aria-readonly is independent of the element's readonly state.
> 
> According to the W3C [1], aria-readonly:
> 
>     Indicates that the element is not editable, but is otherwise
>     operable. See related aria-disabled.
> 
>     This means the user can read but not set the value of the widget.
>     Readonly elements are relevant to the user, and application authors
>     SHOULD NOT restrict navigation to the element or its focusable
>     descendants. Other actions such as copying the value of the element
>     are also supported. This is in contrast to disabled elements, to
>     which applications might not allow user navigation to descendants.
> 
> Because the readonly state in reality is completely disconnected from aria-readonly, an assistive technology is in danger of informing the user that a widget which is editable is not editable. This strikes me as highly undesirable.
> 
> I bring this up for the following reason: The current failing test is failing because we need to implement AccessibilityUIElement::isAttributeSettable(). I implemented it as follows:
> 
> bool AccessibilityUIElement::isAttributeSettable(JSStringRef attribute)
> {
>     // In Atk, things are generally settable if they are not read-only. At the
>     // moment, we identify read only via ATK_STATE_EDITABLE. In the future,
>     // once it is implemented, ATK_STATE_READ_ONLY should also be checked:
>     // https://bugzilla.gnome.org/show_bug.cgi?id=665598
> 
>     return checkElementState(m_element, ATK_STATE_EDITABLE);
> }

Does this get set from calling AccessibilityObject::isAttributeSettable()? Ideally, you'd like your implementation to match that. I'm not sure editable and read-only are always the same thing, and I believe there's also other non settable cases that don't pertain to aria-read only or text fields...

> 
> That gets the test assertions in aria-readonly.html passing with one exception: 
> 
>  PASS ariaTextBoxIsWritable is true
>  PASS ariaReadOnlyAriaTextBoxIsWritable is false
> -PASS ariaReadOnlyTextFieldIsWritable is false
> +FAIL ariaReadOnlyTextFieldIsWritable should be false. Was true.
>  PASS ariaNonReadOnlyTextFieldIsWritable is true
>  PASS htmlReadOnlyTextFieldIsWritable is false
>  PASS textFieldIsWritable is true
> 
> In the case of the failure, ariaReadOnlyTextFieldIsWritable actually IS writable. A user can type in it. Thus it should not be false IMHO.
> 
> Making this test pass as written by modifying the ATK port would have a side effect of making the Orca screen reader telling the user a non-readonly widget is readonly. I consider that unacceptable. Therefore, what should we do?
> 
> Should the element respect the ARIA value and make the widget truly readonly? Should the Accessibility code ignore ARIA attributes that do not jive with reality? Should we move the test to the Mac port (where it fully passes at the moment) and provide a new test which lacks the problematic item? Or something else?
> 

I am not sure what is the right behavior. I'll get James craig from ARIA W3C group to check

> Thoughts?
> 
> [1] http://www.w3.org/TR/wai-aria/states_and_properties#aria-readonly

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.