W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Must "technologies being used" be in a SC's text, if that SC has support in 2 technologies?

From: Gregg C Vanderheiden <greggvan@umd.edu>
Date: Mon, 24 Apr 2017 17:10:58 -0400
Cc: "Repsher, Stephen J" <stephen.j.repsher@boeing.com>, Jason J White <jjwhite@ets.org>, 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>
Message-Id: <B22262C3-9301-40BE-B6E9-510DD28CAC47@umd.edu>
To: Laura Carlson <laura.lee.carlson@gmail.com>
Sorry

Can you include the current wording for the SC you are asking about?

g


Gregg C Vanderheiden
greggvan@umd.edu



> On Apr 24, 2017, at 5:00 PM, Laura Carlson <laura.lee.carlson@gmail.com> wrote:
> 
> Hi Gregg,
> 
> So bringing this back to the specific SC: Adapting text. Can you live
> without the phrase "technologies being used" being in the SC's text?
> 
> Thank you.
> 
> Kindest Regards,
> Laura
> 
> 
> On 4/24/17, Gregg C Vanderheiden <greggvan@umd.edu> wrote:
>> Again - I agree that the phrase would be nice to avoid.
>> 
>> But for some (and only some) SC you may find that you need to have it or the
>> SC will fail general applicability.
>> 
>> The answer isnt in general comments like this — but  in the exploration of
>> specific SC.   For the most part - that has not been necessary.
>> 
>> And discussion of specific SC are underway now.
>> 
>> But if you have a blanket  “we will never use this”  then you might block
>> some SC(s) from being able to get in at all.
>> 
>> So I suggest not arguing in the abstract but rather on a case by case basis.
>>    It is not needed by most all but may be needed by one or another.    So
>> lets see.
>> 
>> 
>> g
>> 
>> 
>> 
>> 
>> Gregg C Vanderheiden
>> greggvan@umd.edu
>> 
>> 
>> 
>>> On Apr 24, 2017, at 3:13 PM, Repsher, Stephen J
>>> <stephen.j.repsher@boeing.com> wrote:
>>> 
>>> 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.
>>> 
>>> ________________________________
>> 
>> 
> 
> 
> -- 
> Laura L. Carlson
Received on Monday, 24 April 2017 21:11:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 08:04:09 UTC