W3C home > Mailing lists > Public > public-low-vision-a11y-tf@w3.org > April 2017

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

From: Alastair Campbell <acampbell@nomensa.com>
Date: Mon, 24 Apr 2017 12:40:01 +0000
To: Gregg C Vanderheiden <greggvan@umd.edu>
CC: Laura Carlson <laura.lee.carlson@gmail.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, Joshue O Connor <josh@interaccess.ie>, Stephen Repsher <stephen.j.repsher@boeing.com>, To Henry <shawn@w3.org>, Jim Allan <jimallan@tsbvi.edu>, Glenda Sims <glenda.sims@deque.com>, Jason J White <jjwhite@ets.org>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Message-ID: <E101D105-FCA1-4761-ABA0-F9F6DD360A3E@nomensa.com>
My point was essentially: Let’s not worry about non-web contexts for the new SCs.

If the “mechanism” language is off-putting to people implementing web-content (our focus), then don’t use it.

If an SC might not be applicable outside of web-content, then note that for future work but it should not impact WCAG 2.1.

That means not worrying about non-web contexts for the text-adaptation SC, so no need for “if the technology supports it”.

Unless there is a “major web technology” where it couldn’t apply? So far we’ve had HTML/CSS/JS/SVG & PDF (where it can apply now). I don’t think it would be an issue for word-processing apps either, if they were included.

Cheers,

-Alastair



From: Gregg C Vanderheiden <greggvan@umd.edu>


Good post
I think I agree with your point about keeping focus on web content.    If I understand it.
but I think we should stick to it even a bit more than you do.

see below

Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On Apr 24, 2017, at 4:08 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:

Gregg wrote:
> I agree that scoping it is not desirable, since it gives a pass to anyone that uses a technology that doesn’t support it.

Or we use the “mechanism is available” language so that technologies without the user-agent ability to override styles can pass if the author includes the mechanism.

Yes.  But we must use this only when we feel that the Mechanism is reasonable


However, I think the basic principle of whether these are scoped to “web content” or aiming for a wider reach is still there.


The name of the Guidelines is  “WEB CONTENT Accessibility Guidelines.”   If they can be more broadly used that is fine — but we do not have the mandate or nor charge to write guidelines for other things.  I think we should stick to Web Content.




If the mechanism language is included that is off-putting to anyone working with web content.

I think I agree with where you are going — but this is and IF-THEN sentence but there is no THEN so I don’t know exactly where you were going with it.




I would prefer to push the accessibility of web content further (in the “web content” guidelines), and mark some SC is less or not-applicable to non-web contexts, which is presumably what the Web2ICT report did?


I agree  we should focus on Web Content.

I don’t think we should be commenting on application outside of Web Content.   Yes that is what the WCAG2ICT report did  — but that was led by a special task force that included people from outside of the web world as well.   Revising WCAG2ICT should involve some external input — and I suggest we stick to web content and not open up non-web content.  That is more work hours than you can imagine and we are having trouble advancing what we have in Web content.



So I agree — stick to web content
I don’t think we should be making judgements outside of web content



G



Kind regards,

-Alastair


Received on Monday, 24 April 2017 12:40:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 April 2017 14:44:35 UTC