Re: Method for minting new Success Criteria

David wrote: I think the Success Criteria describe a state of being...
over time the conditions which cause that state of being can shift to
a certain degree. For
instance, as AT gets smarter, we found it not necessary to fail layout
tables, just recently we made a major change that allowed the title
attribute or
aria label to be an alternative for an image instead of alt text.
Sailesh:
Layout tables never cause a failure unless they used structural  (data
table) markup or caused reading order issues.  Only   layout tables
with more than 2x2 dimension that may be misinterpreted as data tables
by AT, role=presentation is recommended as good practice.
Permitting aria-label or title on img to  represent its accessible
name in certain cases is a technique ... no change in any SC is
conveyed by this.

David wrote: To me mapping to existing success criteria should be our
first line of investigation and only after a thorough exploration of
that should we consider new
Success Criteria inside an extension.
Sailesh:
I surely concur. Refer to my survey comments on COGA which suggests a
new SC in addition to requiring conformance with certain Level AA and
AAA SCs.
For  structure to be exposed by presentation: an SC that is a
reciprocal of 1.3.1  along the following lines will help many user
groups:
"Structure, information and relationships that  is exposed by user
agents or assistive technologies is visually discernible through
default or modified presentational attributes associated with the
elements".
e.g. It will be a failure to suppress presentation for lists, grid
markup, grouping of controls (fieldset/legend), headings and such.

Allen wrote:
I don’t discount the whole “accessibility supported” concept, however,
whether a developer or product owner passes or fails can’t be driven
by changing assistive technologies ...
Sailesh:
 The AT support is a critical  normative conformance  requirement.
Coders may code exactly as per the specf for a technology but if
mainstream AT do not support it for one reason or another, the user is
not well served at all and the accessibility evaluator is obliged to
highlight this as a WCAG 2 failure.
eg. For complex tables including a table that just used colspan (and
no row grouping) there was no alternative but to use headers-id method
. But better support by SRs for colspan and now perhaps rowspan, one
can  rely more on using TH and scope ... on Windows platform.
Thanks and regards,
Sailesh Panchang




On 11/3/15, Hoffman, Allen <allen.hoffman@hq.dhs.gov> wrote:
> Hi david:
>
> I don’t believe SC(s) should be based on if AT can do something, but rather
> if the information is provided which enables the AT to do its part.  So I
> would probably have to strongly disagree with this.  I don’t discount the
> whole “accessibility supported” concept, however, whether a developer or
> product owner passes or fails can’t be driven by changing assistive
> technologies—heck JAWS includes OCR to read things which are completely
> inaccessible but that doesn’t mean such items should pass as they certainly
> aren’t providing the information in a programmatically determinable way.
> There can be some serious magic that makes AT work, but the whole idea is
> that ingeneral there shouldn’t have to be magic to make things work.
>
>
>
>
> Allen Hoffman
> Deputy Executive Director
> The Office of Accessible Systems & Technology
> Department of Homeland Security
> 202-447-0503 (voice)
> allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>
>
> DHS Accessibility Helpdesk
> 202-447-0440 (voice)
> 202-447-0582 (fax)
> 202-447-5857 (TTY)
> accessibility@dhs.gov<mailto:accessibility@dhs.gov>
>
> This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If you
> have received this message in error, please reply immediately to the sender
> and delete this message.  Thank you.
>
> From: David MacDonald [mailto:david100@sympatico.ca]
> Sent: Monday, November 02, 2015 9:53 PM
> To: Hoffman, Allen
> Cc: Wayne Dick; Joshue O Connor; WCAG
> Subject: Re: Method for minting new Success Criteria
>
> Hi Allen
>
>  I think the Success Criteria describe a state of being... over time the
> conditions which cause that state of being can shift to a certain degree.
> For instance, as AT gets smarter, we found it not necessary to fail layout
> tables, just recently we made a major change that allowed the title
> attribute or aria label to be an alternative for an image instead of alt
> text.
> To me mapping to existing success criteria should be our first line of
> investigation and only after a thorough exploration of that should we
> consider new Success Criteria inside an extension.
> We want to make the existing WCAG as robust and modern as possible and
> leverage it's place in legislation etc...
>
>
> Cheers,
>
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902
>
> LinkedIn<http://www.linkedin.com/in/davidmacdonald100>
>
> 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 Mon, Nov 2, 2015 at 7:47 AM, Hoffman, Allen
> <allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>> wrote:
> Mapping them to existing SC(s) as sufficient techniques or failures makes
> sense, but creating supplement SC(s) will not make them normative in legal
> frameworks which connect to the guidelines at a point in time only, not this
> and forward.
>
>
> Allen Hoffman
> Deputy Executive Director
> The Office of Accessible Systems & Technology
> Department of Homeland Security
> 202-447-0503<tel:202-447-0503> (voice)
> allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>
>
> DHS Accessibility Helpdesk
> 202-447-0440<tel:202-447-0440> (voice)
> 202-447-0582<tel:202-447-0582> (fax)
> 202-447-5857<tel:202-447-5857> (TTY)
> accessibility@dhs.gov<mailto:accessibility@dhs.gov>
>
> This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If you
> have received this message in error, please reply immediately to the sender
> and delete this message.  Thank you.
>
> From: David MacDonald
> [mailto:david100@sympatico.ca<mailto:david100@sympatico.ca>]
> Sent: Friday, October 30, 2015 7:38 PM
> To: Wayne Dick
> Cc: Joshue O Connor; WCAG
> Subject: Re: Method for minting new Success Criteria
>
> I think as much as possible we should try to map our findings into the
> existing WCAG which is required by law in many jurisdictions. It will be
> difficult to get jurisdictions to "update" their requirements, but
> addressing them in the existing WCAG will automatically pull them in. As
> long as we can map them to existing SCs
>
>
> Cheers,
>
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902<tel:613.235.4902>
>
> LinkedIn<http://www.linkedin.com/in/davidmacdonald100>
>
> 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 Fri, Oct 30, 2015 at 4:49 PM, Wayne Dick
> <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:
> Hi,
> I think the answer to this question is yes.  We are talking about needs that
> were missed in the first iteration 2.0.  We want the new criteria to carry
> the same legitimacy of the original criteria. The WCAG 2.0 process was very
> credible and objectively good. In all human processes there are oversights,
> but serious critics don't fault WCAG WG on their process or even the
> outcomes. We just need to fill in missing criteria with the same care used
> in the original process.
> Wayne
>
> On Thu, Oct 29, 2015 at 9:02 AM, Joshue O Connor
> <josh@interaccess.ie<mailto:josh@interaccess.ie>> wrote:
> Hi all,
>
> The question has come up 'Do we need to follow the same form as WCAG with
> our extensions success criteria'? A possible method would be to map
> suggested COGA (and other groups) current new SCs (as techniques) to
> existing WCAG success criteria. And if we find that some don’t easily map to
> an existing SC, then that could represent a gap – and therefore the need for
> a new SC.
>
> Therefore one path which could help us to troubleshoot this whole thing
> would be to see all current or proposed SCs – as techniques, then work
> backwards from there.
>
> Another way, is to try to flip any suggested SC into a testable statement.
> If that can't be done, then its likely a technique that can fit an existing
> SC.
>
> Comments, brickbats welcome.
>
> Josh
>
>
>
>
>

Received on Tuesday, 3 November 2015 15:44:58 UTC