Call for Review: WCAG 2.0 Techniques Draft Updates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Call for Review: WCAG 2.0 Techniques Draft Updates

Michael Cooper-2
Dear WAI Interest Group Participants,

The W3C WAI announces a Call for Review of updates to two supporting
documents for Web Content Accessibility Guideline (WCAG) 2.0. *This is
not an update to WCAG 2.0, which is a stable document*. The supporting
documents (W3C Working Group Notes) are updated periodically to reflect
current practices and technologies. The existing Techniques and
Understanding documents remain in place as W3C Notes while the separate
draft updates are under review and the WCAG Working Group addresses
comments.

The following draft updates are available for review as Editors' Drafts:
- Techniques for WCAG 2.0 Editors' Draft
http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/
- Understanding WCAG 2.0 Editors' Draft
http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160105/

The changes are highlighted in diff-marked versions at:
- http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/complete-diff.html
-
http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160105/complete-diff.html 


Please send any comments on these Editors' Drafts by *29 January 2016*.
Because this is a public review of changes to the Working Group Notes,
only comments on changes made since the last Notes will be processed
during this review; other comments will be saved and treated as comments
on the updated Notes once published. Comments and contributions for
additional WCAG 2.0 techniques can be sent via web form or e-mail, per:
- Instructions for Commenting on WCAG 2.0 Documents
http://www.w3.org/WAI/WCAG20/comments/

If you are interested in actively contributing to the development of
additional WCAG 2.0 techniques and support material through the WCAG
Working Group, please see: Participating in WAI
<http://www.w3.org/WAI/participation> and contact Michael Cooper.

For an introduction to the WCAG documents, see:
- WCAG Overview http://www.w3.org/WAI/intro/wcag.php

Please let us know if you have any questions. Thank you in advance for
your comments. Feel free to circulate this message to other lists;
please avoid cross-postings where possible.

Regards,

Andrew Kirkpatrick, WCAG WG Co-Chair
Joshue O Connor, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact


Reply | Threaded
Open this post in threaded view
|

Re: Call for Review: WCAG 2.0 Techniques Draft Updates

Michiel Bijl
C7: Using CSS to hide a portion of the link text contains the following CSS to visually hide an element:

a span {
    height: 1px;
    width: 1px;
    position: absolute;
    overflow: hidden;
    top: -10px;
}

Is there any reason to include the negative top value? If top, right, bottom, and left are not set, the element will stay in the rendered place. This would prevent any mess-ups with—for example—focus styles. A way around this would be to set position to relative on the parent element, but that means extra code that isn’t strictly necessary if top wasn’t set.

—Michiel

Reply | Threaded
Open this post in threaded view
|

Re: Call for Review: WCAG 2.0 Techniques Draft Updates

Michiel Bijl
The method currently listed in section C7 is fine apart from the negative top value. It’s an improvement in that is actually visually hides the thing in position. A very large negative number in margin left just displaces the thing. Similarly, negative text indent messes with other inline elements in that element.

—Michiel

On 08 Jan 2016, at 18:36, ruth tait <[hidden email]> wrote:

how does this improve on the earlier strategy of 
a span {
margin-left: -10000em;

}

Also, the recommendation that link text is hidden using property text-indent: -10000px; as per http://webaim.org/techniques/css/invisiblecontent/ recommendation doesn’t work in browsers for mac. margin-left: -n; with large number does work but haven’t tested with screen readers.

==================
ruth tait
Interdisciplinary student - Graduate Studies
416 900 5631





On Jan 8, 2016, at 11:34 AM, Michiel Bijl <[hidden email]> wrote:

C7: Using CSS to hide a portion of the link text contains the following CSS to visually hide an element:

a span {
    height: 1px;
    width: 1px;
    position: absolute;
    overflow: hidden;
    top: -10px;
}

Is there any reason to include the negative top value? If top, right, bottom, and left are not set, the element will stay in the rendered place. This would prevent any mess-ups with—for example—focus styles. A way around this would be to set position to relative on the parent element, but that means extra code that isn’t strictly necessary if top wasn’t set.

—Michiel



Reply | Threaded
Open this post in threaded view
|

Re: Call for Review: WCAG 2.0 Techniques Draft Updates

Andrew Kirkpatrick-2
Michiel and Ruth,
Thanks for the comments.  
I created an issue for this: https://github.com/w3c/wcag/issues/131 

I also created a pull request to address the issue – you can see the changes here:
https://github.com/w3c/wcag/pull/132/files?diff=split

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 

http://twitter.com/awkawk
http://blogs.adobe.com/accessibility

From: Michiel Bijl <[hidden email]>
Date: Friday, January 8, 2016 at 13:14
To: ruth tait <[hidden email]>
Cc: Michael Cooper <[hidden email]>, WAI IG <[hidden email]>, Andrew Kirkpatrick <[hidden email]>, Joshue O Connor <[hidden email]>
Subject: Re: Call for Review: WCAG 2.0 Techniques Draft Updates

The method currently listed in section C7 is fine apart from the negative top value. It’s an improvement in that is actually visually hides the thing in position. A very large negative number in margin left just displaces the thing. Similarly, negative text indent messes with other inline elements in that element.

—Michiel

On 08 Jan 2016, at 18:36, ruth tait <[hidden email]> wrote:

how does this improve on the earlier strategy of 
a span {
margin-left: -10000em;

}

Also, the recommendation that link text is hidden using property text-indent: -10000px; as per http://webaim.org/techniques/css/invisiblecontent/ recommendation doesn’t work in browsers for mac. margin-left: -n; with large number does work but haven’t tested with screen readers.

==================
ruth tait
Interdisciplinary student - Graduate Studies
416 900 5631





On Jan 8, 2016, at 11:34 AM, Michiel Bijl <[hidden email]> wrote:

C7: Using CSS to hide a portion of the link text contains the following CSS to visually hide an element:

a span {
    height: 1px;
    width: 1px;
    position: absolute;
    overflow: hidden;
    top: -10px;
}

Is there any reason to include the negative top value? If top, right, bottom, and left are not set, the element will stay in the rendered place. This would prevent any mess-ups with—for example—focus styles. A way around this would be to set position to relative on the parent element, but that means extra code that isn’t strictly necessary if top wasn’t set.

—Michiel



Reply | Threaded
Open this post in threaded view
|

Re: Call for Review: WCAG 2.0 Techniques Draft Updates

Chaals McCathie Nevile
In reply to this post by Michael Cooper-2
Hi All,

On Fri, 08 Jan 2016 01:00:38 +0100, Michael Cooper <[hidden email]> wrote:

> The following draft updates are available for review as Editors' Drafts:
> - Techniques for WCAG 2.0 Editors' Draft  
> http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/
> - Understanding WCAG 2.0 Editors' Draft  
> http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160105/
>
> The changes are highlighted in diff-marked versions at:
> -  
> http://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/complete-diff.html
> -  
> http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160105/complete-diff.html

These are sort of helpful, but I'd actually appreciate pointers to the  
changes. In the 3000-page techniques, I counted 5, and the changes seem to  
take more time to work out from the available documents than it will take  
me to write them up for the rest of the world.

(Hint: one of them is to change the description "Script buttons" to  
"Buttons", for HTML buttons).

> Please send any comments on these Editors' Drafts by *29 January 2016*.

Sorry I wasn't able to work on that timeline, but then I don't think it  
matters much when you consider the comments - fixing things as one can  
seems to be the important goal here.

> Because this is a public review of changes to the Working Group Notes,  
> only comments on changes made since the last Notes will be processed  
> during this review; other comments will be saved and treated as comments  
> on the updated Notes once published. Comments and contributions for  
> additional WCAG 2.0 techniques can be sent via web form or e-mail, per:
> - Instructions for Commenting on WCAG 2.0 Documents  
> http://www.w3.org/WAI/WCAG20/comments/

It would have helped to provide the relevant info here:

You can make Pull Requests to http://guthub/com/w3c/wcag but there is a  
request not to do so in the README and a complex build system, you can use  
the form at https://www.w3.org/WAI/WCAG20/comments/onlineform or just send  
email to [hidden email]

In particular it would have helped because it took me about 5 minutes of  
chasing to discover that it is hard to understand how to make a simple  
edit, given the now-unusual method for constructing the Techniques  
document).

All whinging aside, thank you for the updates. I'll work through them and  
provide comments as requested.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  [hidden email] - - - Find more at http://yandex.com

Reply | Threaded
Open this post in threaded view
|

Re: Call for Review: WCAG 2.0 Techniques Draft Updates

Andrew Kirkpatrick-2
Chaals,



On 2/3/16, 20:41, "Chaals McCathie Nevile" <[hidden email]> wrote:

>These are sort of helpful, but I'd actually appreciate pointers to the  
>changes. In the 3000-page techniques, I counted 5, and the changes seem to  
>take more time to work out from the available documents than it will take  
>me to write them up for the rest of the world.

You’re right, it is difficult with the many pages.  We will include a link to the github “compare” view in the future, which won’t help everyone as it is looking at the XML sources, but there is information about the changes entered as descriptions for the various commits that constitute the differences between the current working draft and the master branch.

https://github.com/w3c/wcag/compare/Working-Branch-for-Q1-2016 

>You can make Pull Requests to http://guthub/com/w3c/wcag but there is a  
>request not to do so in the README and a complex build system, you can use  
>the form at https://www.w3.org/WAI/WCAG20/comments/onlineform or just send  
>email to [hidden email]

Right, we would need to make sure to point people to the right branch, which seems to be the issue you found.  If you did know to look at the current working branch it would welcome your comments there through February 10, 2016.  https://github.com/w3c/wcag/tree/Working-Branch-for-Q1-2016 

>In particular it would have helped because it took me about 5 minutes of  
>chasing to discover that it is hard to understand how to make a simple  
>edit, given the now-unusual method for constructing the Techniques  
>document).

Ha!  The process has always been unusual, at least since I joined the group.  We have discussed restructuring how the techniques are authored and generated, but haven’t had the time to get that project moving.

>All whinging aside, thank you for the updates. I'll work through them and  
>provide comments as requested.

Always welcome. The next public review (for the September publication date) will be in July, but we accept comments/pull requests 24/7/365.

AWK
Reply | Threaded
Open this post in threaded view
|

Re: Call for Review: WCAG 2.0 Techniques Draft Updates

Chaals McCathie Nevile
Hi Andrew,

On Thu, 04 Feb 2016 15:16:37 +0100, Andrew Kirkpatrick  
<[hidden email]> wrote:

> On 2/3/16, 20:41, "Chaals McCathie Nevile" <[hidden email]> wrote:
>
>> These are sort of helpful, but I'd actually appreciate pointers to the
>> changes. In the 3000-page techniques, I counted 5, and the changes seem  
>> to take more time to work out from the available documents than it will  
>> take me to write them up for the rest of the world.
>
> You’re right, it is difficult with the many pages.  We will include a  
> link to the github “compare” view in the future, which won’t help  
> everyone as it is looking at the XML sources,

It depends how big teh changes are, but from what I can see these ones  
would have been easy enough to understand from the XML source.

Another option is just to provide a map of the changes as a list...

> but there is information about the changes entered as descriptions for
> the various commits that constitute the differences between the current
> working draft and the master branch.
>
> https://github.com/w3c/wcag/compare/Working-Branch-for-Q1-2016
>
>> You can make Pull Requests to http://guthub/com/w3c/wcag but there is a
>> request not to do so in the README and a complex build system, you can  
>> use the form at https://www.w3.org/WAI/WCAG20/comments/onlineform or
>> just send email to [hidden email]
>
> Right, we would need to make sure to point people to the right branch,  
> which seems to be the issue you found.  If you did know to look at the  
> current working branch it would welcome your comments there through  
> February 10, 2016.  
> https://github.com/w3c/wcag/tree/Working-Branch-for-Q1-2016

Aha. Thanks!

>> In particular it would have helped because it took me about 5 minutes of
>> chasing to discover that it is hard to understand how to make a simple
>> edit, given the now-unusual method for constructing the Techniques
>> document).
>
> Ha!  The process has always been unusual, at least since I joined the  
> group.  We have discussed restructuring how the techniques are authored  
> and generated, but haven’t had the time to get that project moving.

I think the problem isn't so much to have an odd system - as far as I can  
tell these days *all* the cool kids have some weird bespoke thing you need  
to learn before making a Pull Request. But a quick dummy's guide to  
proposing basic changes is really helpful.

>> All whinging aside, thank you for the updates. I'll work through them  
>> and provide comments as requested.
>
> Always welcome. The next public review (for the September publication  
> date) will be in July, but we accept comments/pull requests 24/7/365.

Thanks.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  [hidden email] - - - Find more at http://yandex.com