- From: John Foliot <john@foliot.ca>
- Date: Wed, 10 Dec 2014 15:16:13 -0800
- To: "'James Craig'" <jcraig@apple.com>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>
- Cc: "'Dominic Mazzoni'" <dmazzoni@google.com>, "'Janina Sajka'" <janina@rednote.net>, "'WAI XTech'" <wai-xtech@w3.org>, "'Ted O'Connor'" <eoconnor@apple.com>, "'David Singer'" <singer@apple.com>, "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>
James Craig wrote: > > I have no personal issue against this and reject the implication that my > edits > were somehow personally motivated. If I let personal motivations drive my > edits, > I would never have added the property in the first place. I do, however, > have > *technical* issues with these requirements, as I expressed to the group on > numerous > occasions: I for one am challenging these "technical" issues, while at the same time noting that you have said aloud and publicly, and on more than one occasion, that you/Apple intend to put forth a Formal Objection on this aria-attribute, even though the time for talking FO is far into the future. So some may be forgiven for drawing conclusions in advance, as it DOES appear you've already also pre-judged the outcome of these discussions. > User agents SHOULD provide a device-independent mechanism to allow a user to > navigate > the user agent to content referenced by the aria-describedat attribute. You have previously argued that this phrase "device-independent mechanism" somehow implies that it demands a change to the GUI, yet nothing in the language nor related documents I have read suggest that. You argue that ARIA does not, and was never intended to, change the UI. I disagree, and an informal "social media" poll suggests that I am not the only one who thinks this way. ARIA frequently changes the UI for *non-sighted users*. Take for example the role of "presentation". When applied to table, it completely changes the UI and UX for the non-sighted user - all content inside the table is no longer table data, it is linearized text. As Steve Faulkner stated, "It's an 'aural UI' - the names, roles, states, properties & interaction instructions of HTML in the page, announced to the user by assistive tech". My reading of this requirement is that the term "device-independent" reflects a long-standing requirement we've had that states that the 'trigger' mechanism (GET) for accessing the externally linked resource is device independent (mouse, keyboard, touch, blinking of your eyes, sipping or puffing, etc.). Indie UI defines it this way: "...an abstraction between physical, device-specific user interaction events and inferred user intent such as scrolling or changing values." If my understanding of "device-independent" is incorrect in the context of this discussion, then at the very least might I suggest that a clear defining of that term be added to a Glossary? (perhaps here: http://www.w3.org/TR/di-gloss/) > User agents SHOULD also provide a device-independent mechanism to return the > user's > focus from the descriptive content view to the original content view. Rudimentarily, we can already do this today - use the browser Back button/feature or via <a href="javascript:window.history.back(-1);">Back</a> (both actions BTW already "device-independent" per my understanding of that term)... I am having a hard time understanding why this would be considered an "at risk" issue. > For example, a > user agent MAY provide access to the document or document fragment > referenced by the > aria-describedat attribute in a contextual menu associated with the object. As Rich notes, anything with an RFC 2119 MAY is intended simply as a suggestion, and no-one is required to take this suggestion or hint as anything more than that. (I personally think this is a reasonable suggestion BTW, but fall short of suggesting that it should be anything more than a MAY.) > These requirements are specifically *NOT IMPLEMENTABLE* in any reasonable > way because > they do not follow any established ARIA pattern, We've never done something before, ergo we should never do it? I personally find that a weak argument, as before we had ARIA, we never had a means to attach semantic interaction information to dynamic web content. That didn't stop anyone from starting on ARIA... > and conflict with the defined behavior > of every native host language. I strongly disagree. aria-describedat is essentially nothing more than a semantically-special means of linking an external resource to an in-page asset. This is one of the earliest and most fundamental actions/interactions of the web; it is in effect a special anchor tag that points to a URL, and accessing that linked content via end-user demand is one of the earliest defined behaviors of the web we have - in fact I would go so far as to suggest it is one of THE *defining behaviors* of the web. The draft spec does not specify how the end user "triggers" the request for the linked asset, but only states that it must be device-independent. I maintain that is in keeping with previous requirements elsewhere within WAI. The advantages of the aria-attribute approach are that a) it is a direct, programmatically defined link to its parent, and b) unlike many of the alternate suggestions argued during the @longdesc debate, adding the attribute would result in NO VISUAL INCUMBERANCE TO THE GUI. Authors do not need to provide a "d-link" [sic] on screen, they do not need to include the longer description on the same page as the complex asset requiring the description, solutions such as <details> and <figcaption> mandate an onscreen visual change to the design, etc. While these are/were all arguments in favor of @longdesc, they apply equally to aria-describedat as well. Note, I will continue to advocate that when native host language alternatives that deliver on the same functionality exist, and _have appropriate support_, that they be used instead of the aria-attribute. I think most can agree that this is both logical and appropriate. However, for host languages that lack this feature, providing a means to achieve it via ARIA is the responsible thing to be doing. > The requirements are at-risk, so they are marked as > at-risk. It would be inappropriate if I did *not* note the at-risk status. It was correct to note that they are marked as at-risk; I am questioning why they are currently marked as such, and fear that it may be because the difference between UI and GUI, and whether or not ARIA "changes the UI" is getting in the way of the discussion. JF
Received on Wednesday, 10 December 2014 23:16:53 UTC