RE: aria-details and aria-errormessage mapping [Issue-1044]

I do not support the issue 1044 proposal that browsers should include both aria-errormessage and aria-describedby in the description calculation by concatenating the text content of elements referenced by aria-errormessage and aria-describedby.

 

I believe the downsides of the proposal are so significant that adopting it would exacerbate the very problems aria-errormessage is intended to resolve. Specifically, concatenation by browsers could:

 

1.       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.

2.       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.

3.       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.

4.       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.

 

The aria-errormessage relationship is admittedly a new construct that requires thoughtful implementation by screen reader developers. Supporting it may not be easy, and getting it right may require considerable ingenuity and experimentation. However, it 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.

 

Matt

 

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Thursday, August 25, 2016 10:21 AM
To: surkov.alexander@gmail.com
Cc: accessibility-ia2@lists.linuxfoundation.org; jamie@nvaccess.org; jdiggs@igalia.com; public-aria@w3.org
Subject: Re: aria-details and aria-errormessage mapping [Issue-1044]

 

Alex, Jamie,

 

We discussed this concatenation and Microsoft (Cynthia Shelly) and also Matt King and the more we look at concatenation the worse it looks. This impact more than IA2. It would effect the UIA Mapping for Edge and it creates problems for internationalization whereby we can't put a space in between for all languages.

 

Matt King (Facebook), will respond with another list of problems as will Cynthia. The whole point in the first place was to separate them out in all languages. Another reason is the size of the string that could result.

 

Rich



Rich Schwerdtfeger

 

 

----- Original message -----
From: Richard Schwerdtfeger/Austin/IBM
To: surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com> 
Cc: accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> , jamie@nvaccess.org <mailto:jamie@nvaccess.org> , jdiggs@igalia.com <mailto:jdiggs@igalia.com> 
Subject: Re: aria-details and aria-errormessage mapping
Date: Tue, Aug 23, 2016 3:21 PM
  

Alex,

 

You can't expose aria-details as an action it is a relationship to the extended detail. Who said you were to implement an action? It is not a longdesc.

 

It could point to a details/summary which shows and hides the content itself. The target might be hidden by book readers until the user turns on a facility to show the extended description.

 

 

Here is an example:

 

<img alt="foo" aria-details="baz" src="foo.jpg">

 

<details id="baz">

<iframe src='extendeddescription.html">

<summary>extended description</summary>

</details>

 



Rich Schwerdtfeger

 

 

----- Original message -----
From: Alexander Surkov <surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com> >
To: James Teh <jamie@nvaccess.org <mailto:jamie@nvaccess.org> >
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> " <accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> >, Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com> >
Subject: Re: aria-details and aria-errormessage mapping
Date: Tue, Aug 23, 2016 2:45 PM
  

I'm not yet certain if we agreed upon how to expose aria-details, because longdesc is exposed as an action, which pops up a window with the longdesc, when invoked. My understanding is it is a web author responsibility to implement aria-details UI, and thus action mechanism perhaps is not suitable for it.
 

Jamie, are we going with a new relation for aria-details or can you think of another mechanism to expose it?
 

Thanks.

Alexander.

  

On Sun, Aug 21, 2016 at 8:46 PM, James Teh <jamie@nvaccess.org <mailto:jamie@nvaccess.org> > wrote: 

Hi Rich,

 

Thanks for the clear explanations; I really do appreciate it. Part of the confusion here is that I've unintentionally conflated aria-details with aria-errormessage.

 

Regarding aria-details, what you say absolutely makes sense. Given that, reading the details automatically as a simple message doesn't make sense anyway. Instead, we'd report their presence and let the user act, just as we do for longdesc now.

 

However, this same logic does not apply to errormessage. From an author perspective, I follow that we don't want error messages "stomping" on describedby. However, from an accessibility client perspective, I still don't see the difference. They could still be exposed as part of the description string if they're visible. Aside from being simpler, that would also be better for performance, since an AT doesn't then have to crawl the tree "stringifying" the error messages itself. Can you please explain why this approach doesn't work? Again, please note that I'm talking about the accessibility API mapping, *not* the ARIA attributes; I understand why errormessage and describedby are separate ARIA attributes for authors.


Thanks.

Jamie 

  

On 20/08/2016 12:28 AM, Richard Schwerdtfeger wrote:

>I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. >Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.

>1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that >users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, >the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the >message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.

 

James,

 

I appreciate your willingness to work with us on this. However, let me provide you with the full picture.

 

1. Extended descriptions, referenced by aria-details was requested by the digital publishing industry. The extended description can have all kinds of markup in it and not just HTML: ChemML, MathML, SVG drawings, etc. It is intended as an extended, and sometimes alternative content to better illustrate what is being referenced. For these reasons it is essential that we *always* preserve content. In fact the stringification in many cases could be completely useless to a screen reader user. Also, for these reasons the intent is for it to be visible and not hidden as aria-describedby often is as it must be accessible to all users and not just the blind. Furthermore, there will be instances where the content will be contained within an IFrame within a details/summary element. The big thing here is stringification is simply the wrong thing to do and it must not happen in the browsers for extended descriptions. 

 

The second thing you need to understand is the aria-details attribute was created after months of fighting between browser vendors and people in the accessibility community over longdesc. We don't want to open up that pandora's box again. This is the solution that has come to place. aria-describedby simply does not meet the needs of digital publishing community. What is more they plan to support it in their digital books once a mechanism is put in place, within browsers, to show and hide content reference by aria-details in order to preserve the needs of publishers who don't want extended descriptions rendered by default. We definitely, don't want this functionality applied to aria-describedby.

 

>2. Having errormessage/details as completely separate concepts from description means an AT now has two more things it has to fetch for *every single object that gets focus*. This is >yet another perf problem.

 

Error messages are not the same as extended descriptions and we don't want the same functionality to duplicated with error messages as I described above. The need for error messages arose many major companies rendering visible, popup, error messages for each invalid form entry. They want to have people with disabilities get access to each error messages associated with the invalid control and they want to also have access to the hidden aria-describedby help information they provide for that control. So, stomping on one in favor of the other is a very bad experience. They are indeed distinct and separate concepts.


>3. That said, since the no description/no stringification decision has already been made (despite the concerns above which I raised months ago), relations is the only mapping that >doesn't violate the spec.

 

See above. I hope I have addressed most of your concerns.


>4. Since we're not stringifying as part of description, it does not make sense to map these to the describedBy relation. Thus, we need two new relations.

 

ok


>5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept >that this use case may one day arise.


Joanie Diggs asked for reverse relationships as she wants to be able to traverse back to the source. She is on CC and will be back from vacation next week.

 

Best,

Rich


Rich Schwerdtfeger

 

 

----- Original message -----
From: James Teh  <mailto:jamie@nvaccess.org> <jamie@nvaccess.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com> 
Cc: accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> , jdiggs@igalia.com <mailto:jdiggs@igalia.com> 
Subject: Re: aria-details and aria-errormessage mapping
Date: Thu, Aug 18, 2016 9:45 PM
  

Hi.

 

I've already stated my view on this and asked several questions, but it seems key decisions have already been made, despite a lack of clarification around the concerns I've raised. Given that this has basically become a circular time sink of an argument, I'll provide a final summary of my thoughts.

1. With regard to stringification, I still haven't seen a single solid justification for why errormessage and details are different to description from a user perspective. It's been argued that users should be able to get to the content and read it in its full semantic glory, but no one has pointed out a use case for why that is actually necessary for, say, an error message. Surely, the desired UX for a screen reader is that it should read the error message when it appears, not force the user to press some key to jump there and review it. If we want to read the message, we need to stringify it... and crawling the tree to stringify it ourselves is going to be a hideous perf problem.
2. Having errormessage/details as completely separate concepts from description means an AT now has two more things it has to fetch for *every single object that gets focus*. This is yet another perf problem.
3. That said, since the no description/no stringification decision has already been made (despite the concerns above which I raised months ago), relations is the only mapping that doesn't violate the spec.
4. Since we're not stringifying as part of description, it does not make sense to map these to the describedBy relation. Thus, we need two new relations.
5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept that this use case may one day arise.

Thanks,
Jamie
  

On 19/08/2016 7:21 AM, Richard Schwerdtfeger wrote:

We *cannot* map aria-errormessage or aria-details to a string description. That is absolutely prohibited in the aria specification. It is not to be stringified. Neither is aria-details. Also, in the aria spec. if aria-details and aria-describedby cannot be mapped separately aria-details takes precedence.

 

These are intended to be references so that we can also get access to the structural markup.

 

Now, if you are going to overload the description relationships we need something on the target that indicates they are an error or an extended description. We need to have the distinctions. Object attributes are an option.

 

Rich

 



Rich Schwerdtfeger

 

 

----- Original message -----
From: Alexander Surkov  <mailto:surkov.alexander@gmail.com> <surkov.alexander@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:  <mailto:accessibility-ia2@lists.linuxfoundation.org> "accessibility-ia2@lists.linuxfoundation.org"  <mailto:accessibility-ia2@lists.linuxfoundation.org> <accessibility-ia2@lists.linuxfoundation.org>, James Teh  <mailto:jamie@nvaccess.org> <jamie@nvaccess.org>, Joanmarie Diggs  <mailto:jdiggs@igalia.com> <jdiggs@igalia.com>
Subject: Re: aria-details and aria-errormessage mapping
Date: Fri, Aug 12, 2016 7:42 PM
  

I'd love to hear Jamie on this honestly, but his wording was:

" 

To me, it sounds like errormessage just makes the rules slightly simply
to make life simpler for authors; errormessage isn't presented unless
invalid is true, errormessage must be visible to be presented, etc. That
might be fair enough. However, that doesn't mean it's an entirely
fundamentally separate concept, and thus, there's a good argument for
mapping it to description in a11y APIs (with appropriate rules)."

Do we a real example/scenario where AT has to know that a message on the screen is an error message, and this knowledge would improve the user experience?

  

On Wed, Aug 10, 2016 at 3:45 PM, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote: 

Yes, we heard. So, we need to be able to differentiate an associated error message from a help descriptions. So, you could have a second aria-details relationship in the list of relationships as it would not be stringified (a necessity), BUT you would need to put something on the target ID container to indicate to the AT that it is an error message. Otherwise you need a different relationship. If you are not having reverse relationships and AT vendors would provide a mechanism to go back to the element that was invalid then you would be fine. The use cases we have seen in practices is that multiple form elements become invalid and each has an associated popup error message.

 

We cannot mix descriptions and error messages and the error messages must be visible to all users to be mapped.

 

Rich

 



Rich Schwerdtfeger

 

 

----- Original message -----
From: Alexander Surkov <surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com> > 

To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> " <accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> >, James Teh <jamie@nvaccess.org <mailto:jamie@nvaccess.org> >, Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com> >
Subject: Re: aria-details and aria-errormessage mapping
Date: Wed, Aug 10, 2016 12:48 PM
  

Note, Jamie has been objecting against new relation for aria-errormessage [1].

[1] https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-April/002046.html

  

On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov <surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com> > wrote: 

All reverse relations go at performance/memory cost, I would introduce them iff AT needs them. I'm not sure I see a valid scenario, when they were useful, thus deferring a decision to Joanie and Jamie, who knows more about AT internal gear than me.

  

On Tue, Aug 9, 2016 at 4:58 PM, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote: 

Those would be great. What would you have for reverse relationships? 

 



Rich Schwerdtfeger

 

 

----- Original message -----
From: Alexander Surkov <surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com> >
To: "accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> " <accessibility-ia2@lists.linuxfoundation.org <mailto:accessibility-ia2@lists.linuxfoundation.org> >, James Teh <jamie@nvaccess.org <mailto:jamie@nvaccess.org> >, Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com> >, Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:
Subject: aria-details and aria-errormessage mapping
Date: Tue, Aug 9, 2016 2:12 PM
  

Hi.

ARIA 1.1 got two relation-like attributes: aria-details [1] and aria-errormessage [2], used to connect an element with content providing extra info. Rich mentioned that these attributes are likely need new IAccessible2 relations to expose them, which sounds reasonable. If that's the case, then we should end up with something like:
  

An object containing details for the target object.

IA2_RELATION_DETAILS

An object containing an error message for the target object.

IA2_RELATION_ERROR_MESSAGE

Thanks.

Alex. 


[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
[2] https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage

 

 

 

  

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306 <tel:%2B61%207%203149%203306> 
www.nvaccess.org <http://www.nvaccess.org> 
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie@nvaccess.org <mailto:jamie@nvaccess.org> 

 

  

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306 <tel:%2B61%207%203149%203306> 
www.nvaccess.org <http://www.nvaccess.org> 
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie@nvaccess.org <mailto:jamie@nvaccess.org>