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 <[email protected]> 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 <[email protected]> <[email protected]> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS, [email protected] > Cc: [email protected], [email protected] > 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 <[email protected]> > <[email protected]> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: "[email protected]" > <[email protected]> <accessibility-ia2@lists. > linuxfoundation.org> <[email protected]>, James > Teh <[email protected]> <[email protected]>, Joanmarie Diggs > <[email protected]> <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: "[email protected]" < > [email protected]>, James Teh < > [email protected]>, Joanmarie Diggs <[email protected]> > 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-ia > 2/2016-April/002046.html > > On Wed, Aug 10, 2016 at 8:33 AM, Alexander Surkov < > [email protected]> 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 <[email protected]> > wrote: > > Those would be great. What would you have for reverse relationships? > > > > Rich Schwerdtfeger > > > > ----- Original message ----- > From: Alexander Surkov <[email protected]> > To: "[email protected]" < > [email protected]>, James Teh < > [email protected]>, Joanmarie Diggs <[email protected]>, 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 > www.nvaccess.org > Facebook: http://www.facebook.com/NVAccess > Twitter: @NVAccess > SIP: [email protected] > > > > > -- > James Teh > Executive Director, NV Access Limited > Ph +61 7 3149 3306www.nvaccess.org > Facebook: http://www.facebook.com/NVAccess > Twitter: @NVAccess > SIP: [email protected] > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
