[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 #1 from Joanmarie Diggs (irc: joanie) <jdiggs at igalia.com>  2012-12-10 09:13:53 PST ---
Created an attachment (id=178569)
 --> (https://bugs.webkit.org/attachment.cgi?id=178569&action=review)
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);
}

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?

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.