RE: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

We're making progress :-)

 

Q:  do you believe that the context menu is the authors UI, or the end-users UI? In other words, is there anything in the contextual menu that individual authors can change? 

 

It cannot AFAIK be styled (for example) on a site-by-site basis, and I'm not sure if an author can insert a function/feature into the native context menu (without first installing a plugin) but I believe this to be true as well, so I am unsure how adding support for aria-describedat to the browsers contextual menu is "messing" with the author's UI.  I 100% agree that we should not be making changes to the author's design UNLESS of course the end user needs to do so - and we have a history of supporting that idea, via user style-sheets, and browser settings such as High-Contrast mode, overriding author font-choices, etc. - WCAG Guideline 1.3 "Adaptable: Create content that can be presented in different ways"

 

> I see no reason why a browser couldn't provide additional, optional functionality to allow a user to take advantage of ARIA on the page by adding *new* keyboard shortcuts. If a browser took an existing feature and modified it to behave differently depending on ARIA, I think that'd be a mistake.

 

We are in agreement on both counts, although now I am a bit confused, as that is now adding a new UI pattern to the user-agent, which I thought you opposed ("I officially object/dissent to the language "User agents should provide a device-independent mechanism to allow a user to..." used anywhere in the ARIA spec") - although, don't get me wrong, I am happy to hear your extended thinking here. Support for aria-describedat isn't an existing feature, it will be a new feature (although with roots going back to @longdesc, which is why I think mirroring the support for @longdesc to aria-describedat would be less controversial overall)

 

I believe this is also in accord with NVDA's thinking/stance, previously referenced. I've also long advocated that for questionable UX features like this (where questionable = not every user needs or wants the feature), that an accessibility enhancement like this could/should be a user-configuration setting in the User Agent. 

 

It is my belief that this approach (optional user-setting) could also address the discoverability problem that both @longdesc and aria-describedat currently have/will have. In other words, if a sighted user knows in advance that they want/need longer textual descriptions of complex imagery (or other content), they should be able to "turn on" a visual indication 'switch' that modifies the on-screen content for that individual.  This follows the principle of "Robust", as well as the intent of WCAG 1.3.3 "Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound." (Where currently today, screen readers announce the presence of longer text descriptions, but for sighted users they need to "go hunting" for long descriptions. Note, some of the other browser plugins address this issue by placing an overlay icon [sic] on images that have longer descriptions.)

 

Since aria-describedat is a reformulation of @longdesc in ARIA (shall we all just be honest about that?), I again suspect that the "native" support you provide for @longdesc should also exist for aria-describedat. In this case, there is no "new" UI change per-se, it is simply an extension of something already there.

 

JF

 

 

 

From: Dominic Mazzoni [mailto:dmazzoni@google.com] 
Sent: Monday, December 8, 2014 11:57 AM
To: John Foliot
Cc: James Craig; WAI XTech; Alexander Surkov; Michael[tm] Smith; Daniel Weck; Ted O'Connor; Janina Sajka
Subject: Re: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

 

Q: If ARIA was never intended to augment UI behaviors, why does it say this in the Recommendation? While I note that today no browser provides users the ability to do page-level keyboard navigation using ARIA roles (or landmark elements for that matter AFAIK), this doesn't mean that a) browsers couldn't provide this feature natively, nor b) that this must always be a function/feature of a helper application such as AT software.

Whether or not this is what was originally intended, I think David Bolter's argument is very clear here. Part of the success of ARIA is due to the fact that web authors can trust that ARIA does not affect the behavior of their UI. The spec is not clear in this regard, but it has never explicitly required a browser UI behavior change in the past and I think it'd be a mistake to do so.

 

I see no reason why a browser couldn't provide additional, optional functionality to allow a user to take advantage of ARIA on the page by adding *new* keyboard shortcuts. If a browser took an existing feature and modified it to behave differently depending on ARIA, I think that'd be a mistake.

…and so my question is, if there is a native behavior in HTML that provides accessibility support, should we not ensure that it is also abstracted to ARIA, so that same support can be extended to other markup languages? I'm not stating it MUST at this time, but rather ask if that isn't a reasonable position/assumption to make?

Yes, I agree with this.

 

For example, HTML table cells can have a rowspan or colspan. I think ARIA grids need to be extended to support this too.

 

- Dominic