tagging success criteria #28
Comments
|
For AUDIO wouldn’t you want to include 1.4.2? 1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a http://www.w3.org/TR/WCAG20/#mechanismdef mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A) [Shortened the quoted mail from comment – Eric.] |
|
Thanks @Ryladog, I will include 1.4.2 to audio (and also to video as most videos have audio). |
|
Bingo! Thanks! |
|
I'd suggest adding these to Layout as they also relate to how and where we place info on the screen.
I'd prefer to merge Color and Contrast but see why you did 2 since you are keeping the tags to 1 word... I'd maybe add the following to Control:
I'm not sure 3.2.5 Change on Request needs to be under Links I'd delete Reading since it only has one SC and put that one (3.1.5 Reading Level) under Language |
|
I have adopted the suggestions above. Also I removed the |
|
|
|
Thanks @davidberman, I think that those are good proposals :-) |
|
:) On Tue, Oct 6, 2015 at 10:00 AM, Eric Eggert notifications@github.com
David Berman, RGD, FGDC High Level Advisor, United Nations | GDC ethics chair | Ico-D Sustainability chair | Carleton University Access Network chairAccessibility courses: Ottawa | Europe | Vancouver | Victoria This message may contain proprietary information. Unauthorized |
|
A suggestion I would like to throw into the tagging discussion, is to tag based on activity as well as on functional component. This is done in the Web Accessibility Wizard from AccessiQ and I started doing it when I was exploring the Getting Started Tips. I did an Analysis of SC based on the audiences for the Getting started guides which included 'visual designers', 'ux designers', 'content managers', and 'front-end developers'. There were a few other audiences defined, but these core ones were most easily used for classification of WCAG SC purposes. The value of this is that it makes WCAG more managable for a broader audience as they can focus in on what is relevant to them. Also, for some audiences, functional component language may hide important SC that they need to consider. A prime example is 1.1.1. For someone who is writing copy, would they know that this SC applied to them? Would they select the 'image' tag? Probably not on both counts. More generally, I wonder if the tags selected are too low level for practical purposes. They seem to concentrate on the thing, e.g. image, or focus, or structure. In terms of information architecture there is nothing wrong with that, I just wonder if we are missing an oppotunity to take it a level higher, and try to use the tags to highlight the theme. For example, instead of talking about 'contrast' we could be talking about 'visibility'. This then encompases contrast, keyboard focus, and, perhaps, font size. Or, when considering 'errors' we could be talking about 'feedback' or 'forms'. The former incorporates instructions as well as error messaging. The latter creates quite a strong grouping of things that need to be considered together. Finally, I wonder if some of the tags may be a little obscure. In particular:
Minor:
|
|
I think the tags by activity approach is a brilliant idea, and could ALSO be linked to our tips that classified already by people's role. And so this would allow us to push people to the quickref from the other resources, based on their self-identification. |
|
Thanks for the feedback, @iadawn. The activity-based tagging was discussed before but discarded as the scoping is difficult. I see some advantages to the approach, for example that it is easy for users to identify themselves. On the other hand, it is hard to include as users could have the impression that the resulting success criteria are the only SCs they need to care. I see that this applies to writers that don’t know that they need to care about 1.1.1 – but then I don’t think you will cover all disciplines. What if a project manager looks at this and doesn’t see his tag: Doesn’t that implicit mean that they don’t need to do anything for accessibility? And even if the select “content writers”, there might be success criteria that apply to them indirectly. As for your not on the tags proposal: Are those all where you want to see a discussion on? And if yes, do you have an alternative suggestion for those? (It’s OK if you have not.) |
|
current : heading "keyboard" Current: heading "links" PS : +1 for some activities-based tagging. |
|
current : heading "video" |
|
"Captions" and "Live" can be placed within video or audio. People might get it confused with image captions too. |
|
Agree that clarity, consistency, and compatibility are not likely to be tags that would be understood or helpful. I feel pretty strongly that color and contrast should be kept separate especially because there are SCs specific to each. Someone could choose the "contrast" tag without needing to know about use of color alone as an indicator. Do we have any record of how people configured the current QuickRef? That might be helpful. Or what they search WCAG for? |
|
Regarding including the Use Of Color SC as part of the discussion of Contrast, On 2015-10-12 16:14, sharronrush wrote:
David Berman, RGD, FGDC LinkedIn http://www.linkedin.com/in/bermandavid Twitter @davidberman http://www.twitter.com/davidberman Facebook http://www.facebook.com/davidbberman Skype davidberman.com skype:davidberman.com?chat Google Plus High Level Advisor, United Nations | GDC ethics chair | Ico-D Sustainability chair | Carleton University Access Network chair/Accessibility courses:/ Vancouver | Victoria | Europe | Ottawa This message may contain proprietary information. Unauthorized disclosure/copying/distribution of contents prohibited. |
|
I am on the fence about activity based tags. I would like to see what those proposed tag titles would be so that I could understand the separation between the SC tags and the Activity-based tags. Would it confuse users if they were both included, or Kevin, are you suggesting they would replace the existing list of tags altogether? On another note, I have no issue with the addition of the SC to the tags that people have identified on this issue thread. I would however recommend being critical on which tags should be grouped together. The point of the tags is to single out very specific SC about a very specific topic. |
|
+1 for adding filters ... perhaps adding filters for activities would be an even better solution than adding tags for activities, On 2015-10-12 11:40, sharronrush wrote:
David Berman, RGD, FGDC LinkedIn http://www.linkedin.com/in/bermandavid Twitter @davidberman http://www.twitter.com/davidberman Facebook http://www.facebook.com/davidbberman Skype davidberman.com skype:davidberman.com?chat Google Plus High Level Advisor, United Nations | GDC ethics chair | Ico-D Sustainability chair | Carleton University Access Network chair/Accessibility courses:/ Vancouver | Victoria | Europe | Ottawa This message may contain proprietary information. Unauthorized disclosure/copying/distribution of contents prohibited. |
|
Love the tag approach.
|
We don’t plan for that just now, as every additional filter would need to go through the groups. Of course if someone opens an issue to add a filter, they are welcome to do so.
No, we don’t track any information in those regards. |
|
Update as a result of the survey: Tags
|
I’m not in favor of lumping all of those together, as some of them are special cases.
This is more an UI decision, if people are told that their “contrast is too low”, they might not search for it in color.
Layout is more for the visual aspects, where structure goes more into the coding aspects of WCAG. I think the tool benefits from both terms being separated.
Headings only has heading-specific SCs in it. There is an overlap with the other categories but I’d like to call out headings as a special case and make it clearly visible.
Done.
I put the two of the SCs in Consistency and added them to layout:
Additionally I added the SCs above and 3.2.5 Change on Request to structure. I’m unclear on what to do with compatibility. |
|
Two resolutions from the October 16th EOWG meeting:
|
Also factoring into account the results of the October 16th EOWG meeting.
|
+1 |
Info
This is a collection of “tagged” WCAG 2.0 Success Critera. Those tags are the broad categories of the success criterion and will be the foundation of the new quick reference (prototype). The aim is to have as few tags as possible and as many as necessary. Theoretically, individual success criteria could go without a tag. See also this view with [tags by success criterion](tags by sc).
Tags
imagesvideoaudiocaptionslivestructurekeyboardcolorcontrastautoplaycontroltextlayouttimeflashesnavigationfocuslinkslabelsheadingslanguageclarificationconsistencyerrorscompatibilityThe text was updated successfully, but these errors were encountered: