- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Mon, 21 Jun 2021 12:05:00 +0200
- To: detlev.fischer@testkreis.de
- Cc: "wai-eo-editors@w3.org" <wai-eo-editors@w3.org>
Hi Detlev,
Many thanks for your thorough review and thoughtful comments! Please
find some responses inline:
On 31/05/2021 16:21, Detlev Fischer via WBS Mailer wrote:
>> ---------------------------------
>> (Updated) Draft Script 1.3.1 "Info and Relationships"
>>
>> ----
>> (Updated) Draft script for Success Criterion 1.3.1 "Info and
>> Relationships" (Nearby: previous version and changes made)
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> Looks basically good to me.
> I just note that most content she is likely to have to work with is not
> provided by authors in users' own company ("Fortunately content authors at
> her company are trained to markup page structures") - so this could be a
> confusing signal (implying perhaps, for some in the audience, that
> deficiencies caused elsewhere can be remedied in the user's organisation).
This has been changed to:
- "Fortunately the internal website she mainly uses for her job has
well-designed page structures, so that she can work efficiently."
Here you can find this and other changes made to this script:
- https://github.com/w3c/wai-wcag-videos/pull/54/files
Feel free to comment if these changes do not address your concerns.
>> ---------------------------------
>> (Updated) Draft script for Success Criterion 1.3.4 "Orientation"
>>
>> ----
>> (Updated) Draft script for Success Criterion 1.3.4 "Orientation" (Nearby:
>> previous version and changes made)
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [x] I am comfortable with this script as it currently is (no changes
> suggested)
> * [ ] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> Looks good to me (an alternative would be a 'door slam' message like
> "Please turn your device to portrait orientation" or similar)
The sub-group discussed this idea but felt it would need to be clear
both visually and in audio, and would make the script longer and more
complex. We prefer to keep the script as focused as possible.
>> ---------------------------------
>> (Updated) Draft script for Success Criterion 1.3.5 "Identify Input
>> Purpose"
>>
>> ----
>> (Updated) Draft script for Success Criterion 1.3.5 "Identify Input
>> Purpose" (Nearby: previous version and changes made)
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> This conveys the idea that the critical point of 1.3.5 is automatically
> inserting content stored in the browser via the autocomplete attribute. It
> is not, so this video is misleading. Autocomplete was used because no other
> fitting attribute for purpose was available at the time of writing the SC.
>
> The idea of 1.3.5 is to provide a language-independent identification of
> user purpose so that novel assisitive technology could provide help in some
> other mode, such as displaying extended descriptions of purpose or visual
> icons for elements such as "name" (a user image?) telephone, email,
> address, etc. To my knowledge (correct me if I am wrong), no usable
> implementation of such an assistive technology has been produced since 2.1
> was released 3 years ago. I would skip this SC in the videos since there
> are no known benefits as yet. I would actually propose to seriously
> consider shelving the SC in the next version of WCAG if there is no sign
> that it is going to provide any benefit in real world contexts.
The sub-group opened issue #69 on this script and welcomes your input:
- https://github.com/w3c/wai-wcag-videos/issues/69
>> ---------------------------------
>> Draft script for Success Criterion 2.1.1 "Keyboard"
>>
>> ----
>> Draft script for Success Criterion 2.1.1 "Keyboard"
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> 2.1.1 Keyboard
> Seems to focus on the keyboard interface (speech use) not keyboard input
> per se. This is valild but it may be easier if one (the default) video
> would focus on actual keyboard use? There also seems to be a missing part
> where the file is actually selected by the keyboard alternative to the
> drag-n-drop function. This may be clear visually, but it is not obvious
> from the audio.
The sub-group opened issue #64 on this script and welcomes your input:
- https://github.com/w3c/wai-wcag-videos/issues/64
>> ---------------------------------
>> Draft script for Success Criterion 2.1.2 "No Keyboard Trap"
>>
>> ----
>> Draft script for Success Criterion 2.1.2 "No Keyboard Trap"
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> An example where no key can move the focus may be better. (e.g. a script
> re-focussing a field when the next field is tabbed to).
> What is odd in the example is adding ENTER as a key to just dismiss the
> datepicker. ENTER would most likely already be used to insert the currently
> selected date into the date field. So this should be made clearer if the
> datepicker example is retained.
The sub-group opened issue #65 on this script and welcomes your input:
- https://github.com/w3c/wai-wcag-videos/issues/65
>> ---------------------------------
>> Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)"
>>
>> ----
>> Draft script for Success Criterion 2.1.3 "Keyboard (No Exception)"
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> The example focuses an an act of drawing a straight line which does only
> depend on start and end point? So the video seems to be missing the point.
> A more convincing example might be inserting an electronic signature via
> keyboard rather than signing with a stylus or mouse?
The sub-group opened issue #66 on this script and welcomes your input:
- https://github.com/w3c/wai-wcag-videos/issues/66
>> ---------------------------------
>> Draft script for Success Criterion 2.1.4 "Character Key Shortcuts"
>>
>> ----
>> Draft script for Success Criterion 2.1.4 "Character Key Shortcuts"
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> The example should use modifier keys like ALT or Ctrl rather than the shift
> key. I believe the shift key is not meant to be considered a modifier key
> for keyboard shortcuts (compare
> https://www.w3.org/WAI/WCAG21/Techniques/general/G217).
This script has been put on hold for now due to conflicting suggestions.
>> ---------------------------------
>> Draft script for Success Criterion 2.3.1 "Three Flashes or Below
>> Threshold"
>>
>> ----
>> Draft script for Success Criterion 2.3.1 "Three Flashes or Below
>> Threshold"
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [x] I am comfortable with this script as it currently is (no changes
> suggested)
> * [ ] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> Looks alright to me.
The sub-group opened issue #67 on this script and welcomes your input:
- https://github.com/w3c/wai-wcag-videos/issues/67
>> ---------------------------------
>> Draft script for Success Criterion 2.3.2 "Three Flashes"
>>
>> ----
>> Draft script for Success Criterion 2.3.2 "Three Flashes"
>> For each of your comments, please clearly indicate:
>> * Location: eg. "SC 1.2.2 - Scene 2"
>> * Priority: eg. "[e]" for editorial or "[i]" for important
>> * Current wording:
>> * Suggested revision:
>> * Rationale:
>>
>>
>
> * [ ] I am comfortable with this script as it currently is (no changes
> suggested)
> * [x] Please consider my comments raised in GitHub or in the comments
> field below (for editors' discretion)
> * [ ] I abstain from commenting and accept the decisions of the Working
> Group
> Comments:
> The video does not seem to really illustrate the point - in contrast to
> 2.3.1 it should have a small permanently flashing control, that possibly
> appears large due to strong zoom in? So this would pass 2.3.1 (small area)
> but fail 2.3.2.
Changes have been made to clarify the intended meaning. Please confirm
if this addresses your comments, other please add further comments:
- https://github.com/w3c/wai-wcag-videos/pull/63/files
Regards,
Shadi
--
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Accessibility Strategy and Technology Specialist
Web Accessibility Initiative (WAI)
World Wide Web Consortium (W3C)
Received on Monday, 21 June 2021 10:07:00 UTC