W3C

- DRAFT -

WAI Curricula Task Force Teleconference

25 Aug 2020

Attendees

Present
eoncins, sloandr, Howard, Donal
Regrets
Chair
Daniel
Scribe
sloandr

Contents


<scribe> scribe: sloandr

Signposting:

<dmontalvo> https://github.com/w3c/wai-curricula/pull/243/files/

dmontalvo: discussing a pull request to adjust language to clarify relevant roles and responsibilities
... effort to focus on clarifying the responsibilities of developers, while making them aware that other roles have related responsibilities

<dmontalvo> Dave: Issue is to identify what is others' responsibility

<dmontalvo> https://github.com/w3c/wai-curricula/pull/243/files/

eoncins: agree with pull request language

Howard: pull request language reads better, is clearer

dmontalvo: revised language is more related to WCAG, inspired by "Tips for Getting Started" resource

Dónal Rice joined the call and introduced himself and his role. He is managing a publicly funded programme to develop an Irish curriculum for web accessibility.

<dmontalvo> https://www.w3.org/WAI/tips/

<dmontalvo> https://github.com/w3c/wai-curricula/pull/243

dmontalvo: welcome additional feedback, especially to identify possible edge cases that may not be addressed by proposed language

Keyboard coverage

<dmontalvo> https://github.com/w3c/wai-curricula/pull/242

dmontalvo: discussing a pull request on the most appropriate approach to managing keyboard operation, specifically language on a reworded learning outcome

<dmontalvo> https://github.com/w3c/wai-curricula/pull/242/files

<eoncins> +1

<dmontalvo> Dave: If you are talking about skip to main content links, we may be adding 2.4.7 as well.

Issue #219: screen reader use not suggested

<dmontalvo> https://github.com/w3c/wai-curricula/pull/244/files/

dmontalvo: issue relates to addressing level of expected knowledge of developers about the functionality of screen readers versus the skills in using screen readers in their work

Howard: do not agree that developers do not need to use screen readers, and that using a screen reader in learning activities can help to reinforce learning and clarify context

Donal: had experience of this when creating a course on web accessibility, and cautions against when screen readers are introduced into learning activities—too early, and it can cause confusion especially for iPad/VoiceOver users
... there's also a difference between using screen readers for testing and using screen readers as an everyday assistive technology
... suggest leaving it in, but emphasize the level and type of screen reader knowledge that might be needed to support accessible development

gn: agree developers should have some basic knowledge of screen readers, it should be in curriculum

eoncins: like the proposed changes that emphasize guiding of students in using specific screen reader commands

<dmontalvo> Dave: Good to keep it, maybe compliment it with some other developer tool that underlines markup

dmontalvo: some teaching scenarios may not support guided learning

eoncins: can provide a tutorial or webinar to give basic training on using a screen reader, which may help students.
... also, should guiding students in using a screen reader be a prerequisite for teachers?

dmontalvo: could emphasize this, make this clearer

agreement that this language can still apply to non-guided teaching

Module 6 more practical

<dmontalvo> Dave: Concerns I had was that the module was focused on core requirements without examples of widgets

<dmontalvo> ... Maybe suggest teachers to use a specific type of widgets and then deconstruct it so that the knowledge needed to created it get explained

<dmontalvo> ... I think there is needto turn the theoretical discussion into something more practical

<eoncins> +1 to David

<dmontalvo> Estella: I agree with David that there is a risk of leaving this too broad but not sure how to prioritize different widgets

<dmontalvo> Howard: I think it would be good to provide some kind of example, maybe we have something about this in the tutorials. From that example we could lead people to more advanced stuff

<dmontalvo> Gerhard: Agree with David. Focusing on just one two, or three examples is a really good practice

<dmontalvo> Howard: Make sure that ARIA design patterns and widgets is listed as a resource

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/08/25 16:36:17 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/more pactical/more practical/
Succeeded: s/Sorry can you hear me??//
Succeeded: s/scribe: dmontalvo//
Succeeded: s/scribe: sloandr//
Succeeded: s/Meting: WAI Curricula Task Force Teleconference//
Succeeded: s/scribe sloandr/scribe: sloandr/
Succeeded: s/scribe: sloandr/scribe: sloandr, dmontalvo/
Succeeded: s/oterhs/others/
Succeeded: s/scribe: sloandr, dmontalvo/scribe: sloandr/
Present: eoncins sloandr Howard Donal
Found Scribe: sloandr
Inferring ScribeNick: sloandr
WARNING: Could not parse date.  Unknown month name "25": August 25, 2020
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]