I think Dominic's suggestion on an interface tester with bit flags works well.
Rich
Rich Schwerdtfeger
----- Original message -----
From: James Teh <ja...@nvaccess.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.com
Cc: accessibility-...@lists.linux-foundation.org
Subject: Re: Agreement on concatenation of aria-describedby and aria-errormessage relationships
Date: Tue, Sep 6, 2016 7:19 PM
Fair enough. Thanks for the clear reasoning.
My one remaining concern is performance, but we will clearly need to find an alternative technical solution to this problem. In short, not concatenating means that for every focus event, we need to check for the invalid state plus an errormessage relation and then, if one is found, walk the tree for the target to gather the message. The latter in particular could be unacceptably slow.
On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote:The ARIA working group is against concatenating the description and relationship strings. I will try to summarize:Specifically, concatenation by browsers could:
- Defeat the purposes of aria-errormessage. The aria-errormessage relationship is designed to ensure assistive technology users are as aware of error messages as other users and to enable them to distinguish between error messages and field descriptions. The constraints of ARIA 1.0, and every other accessibility standard and API that preceded it, have forced developers to blend error messages and field descriptions. This blending has long inhibited both the perception and understanding of error messages, which are critical to effective operation of many user interfaces.
- increase cognitive load for users when errors are present. Especially for screen reader users, we already have severe challenges with excess verbosity that forces the user to expend energy sorting out the most important aspects of screen reader feedback. Concatenating potentially very disparate content in this manner would aggravate the verbosity problem.
- Reduce assistive technology flexibility. Part of the power of ARIA is that it gives assistive technologies the ability to present content in the manner best suited for their target audiences. When browsers eliminate semantically relevant distinctions, this type of flexibility is diminished. If this concatenation were performed, it would essentially eliminate the semantic distinctions. If an assistive technology developer wanted to present the field description separate from the error messages, the developer would be forced to ignore the browser-computed description when error messages are present and reconstruct the description computation within the assistive technology.
- Lead either browsers or authors to devise their own string-based tokenization capability. Because aria-errormessage is a separate relationship, there will be designers and developers who want to ensure there is a method for parsing the string into its separate components. This would reduce the robustness of the solution and create both inconsistencies and complexity, especially when localizing implementations.
- Introduce serious problems with globalization: namely there is no clean way to concatenate the 2 strings in a way that will make sense. We cannot put in a space as some languages don't have them (Mandarin). Concatenating them together does not read properly.
The aria-errormessage relationship is intended to address long-standing accessibility issues faced by both developers and end users. The energy required to find effective remedies to those issues will definitely pay dividends for assistive technology users.Would each of you weigh in. Again this is now holding up 3 working groups going on 3 weeks now. Do we agree on not concatenating the two strings?Rich
Rich Schwerdtfeger--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
