> > 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
Received on Monday, 8 December 2014 19:56:59 UTC