- From: Repsher, Stephen J <stephen.j.repsher@boeing.com>
- Date: Mon, 24 Apr 2017 19:13:30 +0000
- To: "White, Jason J" <jjwhite@ets.org>, Laura Carlson <laura.lee.carlson@gmail.com>, Gregg C Vanderheiden <greggvan@umd.edu>
- CC: Alastair Campbell <acampbell@nomensa.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, Joshue O Connor <josh@interaccess.ie>, To Henry <shawn@w3.org>, Jim Allan <jimallan@tsbvi.edu>, Glenda Sims <glenda.sims@deque.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Jason has pinpointed the exact reason why I oppose any language that gives an author power to simply skip over an SC just because they use a technology with poor accessibility support. Any exceptions should have clear restrictions and backup accessibility support (as does "Images of Text", for example). For WCAG 2.1, with or without the language is probably not the question. Rather, what is the compromising language for now until we get to Silver? It seems to me that we could argue all day and night about which web technologies are "major", but in order to talk about future-proofing we need to discuss responsibility. And currently, the responsibility chain has a very weak link from author to user that is only going to get more important to strengthen as we talk about adaptation, linearization, personalization, and other needs. Authors have full control over their content, including which web technologies they choose and adhering to appropriate standards. The WCAG buck stops there obviously in its current form. The problem is that even if UAAG (and ATAG) were married to it today, trying to remain technology-agnostic would result in the same core issue: no responsibility is formally placed on web technology developers (at least not outside the W3C). If we really want to produce guidelines which are both independent of current technology & cognizant of future ones, then they are going to have to draw a line in the sand somehow (e.g. only conform with technologies formally reviewed and approved by the W3C or otherwise conform to the nonexistent Web Technology Accessibility Guidelines). Steve -----Original Message----- From: White, Jason J [mailto:jjwhite@ets.org] Sent: Monday, April 24, 2017 10:08 AM To: Laura Carlson <laura.lee.carlson@gmail.com>; Gregg C Vanderheiden <greggvan@umd.edu> Cc: Alastair Campbell <acampbell@nomensa.com>; Andrew Kirkpatrick <akirkpat@adobe.com>; Joshue O Connor <josh@interaccess.ie>; Repsher, Stephen J <stephen.j.repsher@boeing.com>; To Henry <shawn@w3.org>; Jim Allan <jimallan@tsbvi.edu>; Glenda Sims <glenda.sims@deque.com>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org> Subject: RE: Must "technologies being used" be in a SC's text, if that SC has support in 2 technologies? > -----Original Message----- > From: Laura Carlson [mailto:laura.lee.carlson@gmail.com] > If that is the case, do we need the "technologies being used" language > on all of our SCs? [Jason] I don't support the "technologies being used" language at all. I think we should acknowledge that not every technology can be used to meet WCAG 2.1. If it works with all of the major technologies in use today, I think this is sufficient; and as I argued earlier, HTML+CSS+JavaScript+SVG+PDF comprise most of what we need to consider at the moment. Future technologies will need to be designed with accessibility in mind, and WCAG will help to inform those design decisions. I do agree with Gregg that major user interface revolutions may well be coming, but they need to be based on implementation technologies that adequately support accessibility. ________________________________ 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, 24 April 2017 19:14:21 UTC