Re: Alternative Silver / WCAG 3.0 conformance model proposal

Thanks Detlev,

I find this very interesting and as another viable option here

** katie **

*Katie Haritos-Shea*
*Principal ICT Accessibility Architect*


*Senior Product Manager/Compliance/Accessibility **SME*
*, **Core Merchant Framework UX, Clover*


*W3C Advisory Committee Member and Representative for Knowbility *


*WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy,* *IAAP CPACC+WAS = *
*CPWA* <http://www.accessibilityassociation.org/cpwacertificants>

*Cell: **703-371-5545 <703-371-5545>** |* *ryladog@gmail.com
<ryladog@gmail.com>* *| **Seneca, SC **|* *LinkedIn Profile
<http://www.linkedin.com/in/katieharitosshea/>*

People may forget exactly what it was that you said or did, but they will
never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to
dictate where we are going.






On Thu, Aug 13, 2020 at 1:09 PM Wilco Fiers <wilco.fiers@deque.com> wrote:

> Hey folks,
>
> I've been thinking about this a bunch, and I haven't yet come up with
> something that doesn't cause a heap of problems. I did want to share my
> thoughts on this so far, as I hope it might trigger some ideas on solutions.
>
> My biggest question I have at the moment is can we come up with a grading
> mechanism that is reasonable, that can be done consistently, without
> significantly increasing the effort it would take to do a test.
>
>
> At the foundation of that is that we need some sort of mechanism by which
> we count the number of fails, or passes, or both. It may not seem too
> difficult for us to count for example the number of images on the page, but
> the more you think about this, the harder it gets. For WCAG 2, it really
> doesn't matter if an image map is one image or one plus however many areas
> there are. But if having 1 problematic image gets you "good" in WCAG 3, and
> having 5 gets you "reasonable", suddenly being able to do that starts to
> matter a whole lot.
>
> Scoring mechanisms based on numbers of issues makes WCAG testing far more
> difficult then it is today. Throwing tools at it might mitigate that
> problem, but it creates another one. Tools have a very different
> perspective then humans do. If we write this to work well for tools, it
> might not be viable for humans to do that same evaluation, and vice versa.
> Even between tools perspectives differ substantially. A tool with access to
> the web extension APIs will find certain things very easy that are nearly
> impossible for other tools (there are other APIs like that too). What do we
> do there? Force all tools toward one particular browser that happens to
> have the APIs we like best? Lowest common denominator? What about non-HTML
> tools?
>
>
> The most promising idea I've come up with is to instead of having WCAG
> define the unit of counting, have that be based on scope. Your conformance
> claim can say something like, this page consists of three sections; header,
> main, footer. The header and main score good, the footer scores poor for
> screen reader users, but good for all other user groups. Or you can break
> that same thing down into paths where some paths score higher than others.
>
> That avoids the problem of counting... sort of. This won't work well if we
> break scope down to the element level. Also if someone insists on a pass or
> fail at a page level, there it still comes to a complete fail, even for a
> minor issue.
>
>
> Wilco
>
> On Thu, Aug 13, 2020 at 5:43 PM Detlev Fischer <
> detlev.fischer@testkreis.de> wrote:
>
>> Hi Alastair,
>>
>> I think I would still prefer to rate SCs (or functional outcomes / FO in
>> WCAG 3.0) on the basis of what the best and worst possible implementation
>> is for that particular FO, and use those to define the end points of the 5
>> point scale rather that using that scale to also reflect priorisation
>> *across* FOs. I think that should be done on another level. It may well be
>> that priorisation (or relative weight) of FOs depends on contexts and may
>> be defined differently for different types of applications, for example.
>>
>> In my view, what is urgently needed for the scoring model is a separate
>> 'stop condition' for flagging critical issues. To take an example: SC 3.1.2
>> "Language of Parts" (or a related FO) might fail on an information-oriented
>> site with some publication titles without lang markup (0/5) but that would
>> not be critical for such a site. On the other hand, if you are testing an
>> online translation service, failure of 3.1.2 (0/5) should be flagged as
>> critical, because it is. So, if you have a sample of such an application
>> containing the view with the main translation function and besides that, 5
>> other views like FAQ, imprint, version history etc., a 5/5 rating on those
>> other views (for lack of foreign language content) must not bury the
>> critical issue by raising the overall score of 3.1.2 in aggregation across
>> views sampled. Or reporting may present the aggregate score, but clearly
>> flag the failure. Flagged failures could be used prevent overall
>> conformance of the chosen scope if we accept the condition "no critical
>> failures in any functional outcome across the sampled views" - but that
>> needs to be debated, of course.
>>
>> Best,
>> Detlev
>>
>> Am 13.08.2020 um 15:25 schrieb Alastair Campbell:
>>
>> Thanks for that Detlev,
>>
>> I'm not sure if your proposal would actually be simpler overall (compared
>> to where the others might get to), but I really like some aspects like the
>> "Adjectival or 5 point scoring" slide. That explains something where there
>> are many options in a very straightforward way.
>>
>> It occurs to me that some prioritisation could be built into that with
>> much less controversy.
>>
>> For example, having flashes on the view scores 0/5. If we decided that
>> "language of the page" (environment, whatever) was less of an issue, it
>> could score 2/5. (Or 3 if the user group is known and the default works?)
>>
>> That's a hypothetical, just pointing out that when you have finer gained
>> scoring than pass/fail there is inherent prioritisation /within/ the
>> guidelines, no need for a separate prioritisation.
>>
>> Cheers,
>>
>> Alastair
>>
>>
>> Apologies for typos, sent from a mobile.
>> ------------------------------
>> *From:* David MacDonald <david@can-adapt.com> <david@can-adapt.com>
>> *Sent:* Wednesday, August 12, 2020 5:30:48 PM
>> *To:* Detlev Fischer <detlev.fischer@testkreis.de>
>> <detlev.fischer@testkreis.de>
>> *Cc:* WCAG group <w3c-wai-gl@w3.org> <w3c-wai-gl@w3.org>
>> *Subject:* Re: Alternative Silver / WCAG 3.0 conformance model proposal
>>
>> Hi Detlev
>>
>> I really like your direction, and it shows a lot of thought and work.
>>
>> Cheers,
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>> Mobile:  613.806.9005
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://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 Wed, Aug 12, 2020 at 6:41 AM Detlev Fischer <
>> detlev.fischer@testkreis.de> wrote:
>>
>> For those who were not present in yesterday's conformance deep dive, I
>> just want to put the link to an alternative proposal that I have now
>> outlined in response to the 2 existing proposals by Rachael and John.
>>
>> I fear that in both proposals discussed so far, the scoring approach
>> will be very complex and hard to understand. I am also uncertain whether
>> the complete revamp of the structure into guidelines/methods is justified.
>>
>> My proposal tries to envisage WCAG 3.0 more as an extension of WCAG 2.X,
>> turning pass/fail into a graded scoring scheme with 5 points (what has
>> been called 'adectival rating'). In that way, it supports the inclusion
>> of new success criteria that are not easily amenable to a pass/fail
>> rating. The proposal also allows the definition of paths (based on user
>> tasks) as an aggregate for scoping conformance claims.
>>
>> Here is the link:
>> https://docs.google.com/presentation/d/1dV1moNnq-56sS1o84UCKkc_g-gE10X6Y/
>>
>> This is just a sketch, and hopefully a basis for discussing alternatives
>> that seem to me more workable than what we have so far.
>>
>> Detlev
>>
>> --
>> Detlev Fischer
>> DIAS GmbH
>> (Testkreis is now part of DIAS GmbH)
>>
>> Mobil +49 (0)157 57 57 57 45
>>
>> http://www.dias.de
>> Beratung, Tests und Schulungen für barrierefreie Websites
>>
>>
>>
>> --
>> Detlev Fischer
>> DIAS GmbH
>> (Testkreis is now part of DIAS GmbH)
>>
>> Mobil +49 (0)157 57 57 57 45
>> http://www.dias.de
>> Beratung, Tests und Schulungen für barrierefreie Websites
>>
>>
>
> --
> *Wilco Fiers*
> Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>
>