- From: White, Jason J <jjwhite@ets.org>
- Date: Mon, 9 Nov 2015 21:57:00 +0000
- To: Matt King <a11ythinker@gmail.com>
- CC: "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, John Foliot <john.foliot@deque.com>, Steve Lee <steve@opendirective.com>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
> On Nov 9, 2015, at 11:21, Matt King <a11ythinker@gmail.com> wrote: > > An important part of thinking about the ARIA strategy moving forward is discussing which aspects of the solutions to these systemic problems fall within the scope of the accessibility standards and other W3C deliverables. We need to have realistic expectations. > Deciding which technology or combination of technologies should be used to meet various accessibility requirements ultimately affects the architecture of the Web as a whole. The options should be evaluated from an architectural perspective, not merely from that of seeking quick or convenient solutions. I think there is benefit to be gained by meeting accessibility requirements with features that attract multiple communities of interest and which have use cases beyond accessibility. For example, the HTML 5 details element is under consideration for its potential to associate extended descriptions with content, but it is not and was not designed to be an “accessibility” feature. > While I am all for making ARIA consumable and want to do all we can to make it as easy as possible for developers to implement, we also need to remember that complexities at the lowest levels are unavoidable. We have a huge and complicated problem space, and no amount of standard writing will make it simple. > I agree. If you decide to invent your own unique wheel, then doing so comes with attendant responsibilities. This has always been so. We need the tools for constructing new components as well as a good prefabricated set for authors to use when inventing something new isn’t the right solution. I think more can be done to assist developers who elect to be inventive, however, not only in education and documentation but also in programming environments and code testing tools. We’re still working without a good authoring/programming tool infrastructure in place to support accessibility, and expecting developers to compensate by doing and testing their work manually for the most part. I also think the number of layers between Web application and AT (e.g., screen reader) is unfortunate: ARIA -> user agent internal accessibility API -> platform-specific accessibility API -> interprocess communication -> screen reader - plenty of scope for bugs and inconsistencies even for the same UA with different client AT or different operating systems. ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________
Received on Monday, 9 November 2015 21:57:34 UTC