Re: WCAG Agenda April 7 2015

This all rings true to my memory.

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Sun, Apr 5, 2015 at 11:06 PM, Gregg Vanderheiden <
gregg@raisingthefloor.org> wrote:

> Agree.
>
> Extensions don’t change standards, or add to the standards.   For example
> SVG is an extension of HTML but doesn’t change the HTML standard nor what
> it takes to conform to the HTML standard.
>
> Also, agree that WCAG was meant to be flexible enough to apply to
> different platforms, devices, etc.   In fact the WCAG2ICT task force looked
> at what it took to apply WCAG to e-documents (not on the web) and software
> in general.   Their conclusion after a year of work was that it did apply
> with basically just changing the words Web to documents and software.
>  (they did find that a couple provisions that talked about “sets of” didn’t
> occur much (rarely) in docs and especially software.  But when they did
> occur - they would still apply as written.
> It is important to note that the group also concluded that WCAG didn’t
> apply directly to “closed platforms” because WCAG assumed the ability to
> use AT to provide access.  Closed functionality is defined as functionality
> where AT is prevented from being used by  physical design or policy.   So
> the  WCAG2ICT task force concluded that for closed functionality — the
> effects of WCAG (esp the “programmatically determinable” provisions - where
> AT was assumed) would have to be provided in other ways  - since AT can’t
> be used with closed functionality.
> WCAG obviously doesn’t provide the guidelines for the hardware parts of
> devices either — so those need to be added to WCAG  (and are in 508) along
> with platform requirements.
>
>
> Perhaps some of what we are talking about can be addressed with new
> techniques for meeting existing provisions in different platforms or
> devices.
> while others might be extension provisions.
>
> but even in an extension - if conformance is involved - the provisions all
> need to meet the normal provisions for a ‘requirement’ or success
> criterion.
>
> It will be interesting to see if we are able to identify any new
> provisions that meet the usual criteria for being a requirement.
> Here are 4 - (I might have forgotten one)
>
>    1. *Is it measurable and testable?* - (e.g. clear criterion that are
>    pass fail) (you can’t require something if the person cannot determine if
>    they have passed)
>    2. *Is it clear/internally consistent *—  if you have 10 people
>    evaluate 20 pieces of content against a provision - there will be high
>    level of agreement on whether the pieces of content meet the criterion (e.g
>    high inter-rater reliability)  (It isnt fair if people can’t generally
>    agree on whether something passes or not)
>    3. *Can the provision can be applied across *
>       1. *all types of pages *(static, dynamic, web apps),
>       2. *all levels of content* (simple through technical such as
>       physics sites, medical sites etc.)
>       3. *all devices that the content will be shown on *(or evaluated
>       on)
>       4. *WITHOUT fundamentally changing the content, its purpose or its
>       effectiveness.*  (e.g. rewiring a medical or physics site
>    4. *Is it practical to apply this to all web sites in the world (that
>    we want to use the guidelines)*
>       1. (e.g. we did not include a sign language alternative for all web
>       content in WCAG 2.0 because the cost would be enormous and there simply are
>       not enough people skilled in transforming all sites into sign language to
>       provide re-presentation in sign language of even a small fraction of all
>       the web pages — even if the web wasn’t changing every day).    ( similar
>       problem would occur if we wanted all web pages to be in plain language.
>       Trying to convert just one site into plain language points out the enormous
>       skill and time required to do this.  We did it for a simple 4 page
>       “research subject disclosure form” and it took days and our whole team.
>       And this would be true for any complex site.
>
>
> In WCAG 2.0 we had many more things that we identified that could make
> this type or that type of page more accessible to different groups.  And we
> included many as advisory - and need to keep identifying and documenting
> more.  But before it can be a general requirement for Web pages - it would
> need to meet all of the above - and that was much harder.   A smaller set.
>
> In thinking about creating any guidelines for general application (all
> websites) the above list of 4 criteria is a good first test to see if the
> idea/ provision can qualify — or whether it would need to be an advisory
> technique to be applied when and where appropriate.  (We ran into this in
> WCAG many times - and it is very painful to not be able to include good
> advice because it couldn’t be a provision.  In at least one case we
> included a testable provision just so that we had a place to attache a lot
> of good advisory techniques that would couldn’t get in as success criterion
> because we couldn’t satisfy the criterion for doing so.
>
> *IDEA  - Perhaps we can create more requirements if we constrain the scope
> of their application.*
> for example - *Guidelines for general, non-technical information,
> transaction and shopping pages*
> If we were talking about general information pages — or general
> transaction pages  (e.g. shopping) we could come up with guidance that
> would be more far reaching (and still practical)  than if we tried to
> create guidelines for application across all web sites and content types
> (where many of the provisions would not be possible highly technical
> information or highly complex operations like programming or creating
> spreadsheet-like formulas
>
> Just a thought.  Perhaps we can push the envelop if we don’t try to
> include all types/sites in the envelope like WCAG had to.
>
> *gregg*
>
> ----------------------------------
> Gregg Vanderheiden
> gregg@raisingthefloor.org
>
>
>
>
> On Apr 5, 2015, at 9:16 PM, Mike Elledge <melledge@yahoo.com> wrote:
>
> A couple of things come to mind for discussion. Are the extensions meant
> to be additions to WCAG 2.0 for specific contexts? Or are there instances
> where they might override WCAG 2.0 given a particular context?
> By definition WCAG 2.0 is supposed to be flexible enough to apply to
> different platforms, devices and languages (no longer HTML-centric) on the
> web, but once we apply it outside of the usual context, for example, in
> automotive interiors or on something like Google glass, are all bets off? I
> like the idea of extensions being supplementary, but I think we have to be
> careful to avoid offering them as reinterpretations of existing WCAG
> criteria. Otherwise we will cause confusion as well as weaken the authority
> of WCAG 2.0.
>
> I think we also want to avoid re-writing WCAG every time a new use case
> appears. :^)
>
> Mike
>
>
> On Apr 4, 2015, at 9:53 AM, alands289 <alands289@gmail.com> wrote:
>
> Since WCAG 2.0 is stable and is also an ISO standard, is there a challenge
> in adding to it via extensions?
> These are almost like revisions.
>
> Before we determine what they all should be we need to determine how to
> relate new things to the already approved WCAG 2.0 that governments and
> organizations are using.
>
> From the eyes of the user:
> What authority do these new items have?
> Why should I do them, all I really need to do is WCAG 2.0?
> Who says these are related and required?
>
> Best Regards,
> Alan
>
>
>
> Sent from my Samsung Galaxy Tab®4
>
>
> -------- Original message --------
> From: Joshue O Connor <joshue.oconnor@cfit.ie>
> Date:04/03/2015 7:43 AM (GMT-05:00)
> To: WCAG <w3c-wai-gl@w3.org>
> Subject: WCAG Agenda April 7 2015
>
> The WCAG WG will be meeting on Tuesday, 7th April  2015  at 11AM Eastern US
>
> (Length: up to 90 minutes)
>
> Bridge: +1.617.761.6200  (US) Passcode: 9224#
>
> IRC: irc.w3.org<http://irc.w3.org>  port: 6665 channel #wai-wcag
>
> Scribe list:https://www.w3.org/WAI/GL/wiki/Scribe_List
>
> Agenda
>
> 1)    TPAC final call
>
> 2)    Extension model discussion:
>
> Including the sub topics:
>
> Background pointers
> What type of extensions?
> Will extensions be A, AA, AAA?
> Will extensions conform to WCAG requirements for success criteria?
> Categorisation of current open issues in the context of the extension model
>
> 3) WCAG working group and public engagement/interaction
>
> Thanks
> --
> Joshue O Connor/Andrew Kirkpatrick
> WCAG working group co-chairs
>
>
>
>