RE: [wbs] response to 'Curricula Designer Modules Publication Approval'

Hi Jenn,

Thanks so much for your comments in the survey and responding to Daniel's explanation of response to your comments. This engagement is awesome to see. While thinking about it, I have some suggestions on how we can make this more efficient for you and effective for the Editor of any resources. Do you mind if you and I get in a quick 15-20 minute meeting next week to talk about it. It won't take long and I think it will really help out in these areas. Your feedback is so important and I want to be sure we get it at the right time so that it can have the most impact. 

If you are able to meet, please send me (directly) a few times when it will work and I will see if I can get that time freed up on my calendar.
Looking forward to chatting with you again. It has been too long.

Thanks,
Brent

Brent A. Bakken  |  Director, Accessibility Strategy & Education  |  (512) 202-1087  |  brent.bakken@pearson.com  |  Pearson



-----Original Message-----
From: Jennifer Chadwick <jcha@siteimprove.com> 
Sent: Wednesday, February 2, 2022 10:11 AM
To: Daniel Montalvo <dmontalvo@w3.org>
Cc: Bakken, Brent <Brent.Bakken@Pearson.com>; wai-eo-editors@w3.org
Subject: RE: [wbs] response to 'Curricula Designer Modules Publication Approval'

Hi Daniel,

Thanks so much for taking the time to respond to my feedback.   My responses are that I am good with your explanations and reasoning!

I appreciate you showing me where the content I suggested is already in the text, and I agree with your divisions of design and developer responsibility.

Best,
Jenn


Jennifer Chadwick, CPACC, CUA 
Pronouns: She / Her
Senior Accessibility Consultant, International
 


 

jcha@siteimprove.com
 

+1 905 483 9139
 

Suite 700, 110 Yonge Street, Toronto, Ontario, Canada M5C 1T4
 



 


-----Original Message-----
From: Daniel Montalvo <dmontalvo@w3.org> 
Sent: February 2, 2022 9:46 AM
To: Jennifer Chadwick <jcha@siteimprove.com>
Cc: Brent Bakken <Brent.Bakken@Pearson.com>; wai-eo-editors@w3.org
Subject: RE: [wbs] response to 'Curricula Designer Modules Publication Approval'

Hey Jenn,

Thanks for your feedback. Please see my replies below.

> -----Original Message-----
> From: Jennifer Chadwick via WBS Mailer <sysbot+wbs@w3.org>
> Sent: Saturday, January 22, 2022 3:03 AM
> To: jcha@siteimprove.com; dmontalvo@w3.org
> Subject: [wbs] response to 'Curricula Designer Modules Publication Approval'
> 
> The following answers have been successfully submitted to 'Curricula 
> Designer Modules Publication Approval' (Accessibility Education and Outreach Working Group (EOWG)) for Jennifer Chadwick.
> 
> >
> >
> > ---------------------------------
> > About this survey
> >
> > ----
> > This survey form collects responses to the EOWG publication approval 
> > of the WAI Curricula Designer Modules.
> > Estimated review time: Medium. Focus on list of changes after 
> > thorough review (below).
> >   WAI Curricula Designer Modules final draft for approval. Includes:
> >      * Module 1: Visual Design
> >          * Module 2: Information Design
> >          * Module 3: Navigation Design
> >          * Module 4: Interaction Design
> >          * Module 5: Images and Graphics
> >          * Module 6: Multimedia and Animations
> >          * Module 7: Forms Design
> >       Changelog shows changes since the thorough review version of 
> > late December 2021.
> > Diff shows changes in GitHub diff format since the thorough review 
> > version of late December 2021.
> >
> >
> > Note: Please do not include in this survey copy edits, typos, 
> > punctuation, etc. that do not need Working Group review; instead, 
> > please make copy edits and such to directly in Github (fork, edit, 
> > pull request) (or e-mail them to: wai-eo-editors@w3.org).
> >
> > As this is an approval to publish, we ask for your comments to have 
> > extra indication of level: [ED] = editors' discretion, [High] = 
> > important to be addressed before publication.
> >
> > For each of your comments, please clearly indicate:
> >  * level: [ED-low] or [ED-med] or [High] (do this in the title of 
> > comments in GitHub, too)
> >  * location: (such as: "Module 1: Visual Design" "Topic Flexible 
> > Layouts". under Learning Outcomes heading, third bullet")
> >  * current wording:
> >  * suggested revision:
> >  * rationale:
> > Please use GitHub if you are comfortable, instead of putting 
> > comments in this survey. Fork & Edit links for pull requests are at 
> > the bottom of each page. Links for new issues: [ED-low] , [ED-med] , 
> > [High]
> >
> Comments:
> [ED-low] Module 1 > Topics to Teach > "Topic-Flexible Layouts"  simply 
> add the words "mobile" and "tablet" to these bullet points to clarify what they
> are related to.   E.g. "design layouts to support text zooming.... through
> multiple breakpoints, e.g. on desktop, mobile phone and tablet devices."
> 
> - design layouts to support text zooming and enlarging in different 
> viewport sizes and through multiple breakpoints
> - design layouts that adapt their content view and operation to 
> portrait and landscape orientations
> - design layouts with target sizes that adapt to different screen 
> sizes, screen configurations, and style sheets, for example when 
> creating responsive designs
> 
> [ED-low] Module 2 Information Design > Topics to Teach > Tables.  Add an extra bullet point:
> 
> Students should be able to:
> 
> - explain why it is not best practice to build page structure using tables for presentation only.
> 

This is covered in the developer part. "identify tables that are used for layout purposes rather than to present data, and write code for such layout using CSS techniques instead of using HTML structures"

We discussed this before and concluded that determining the layout is a designer's responsibility, whereas coding the different types of tables accessibly is a developer's responsibility.

> [ED-low] Module 4: Interaction Design > Competencies - Instructors
> 
> Does it make sense to include a requirement for some training in 
> speech dictation software (i.e. Dragon NaturallySpeaking?).  This is a 
> core learning outcome, just wondering if an instructor might need to 
> demonstrate this, or at least be familiar with the instructions/ behaviours of the software, in order to teach it.  Recognize this software is expensive and hard to access for the average instructor. :) Maybe even familiarity with the commands could be added to the Competencies list.

That would be weird given current structure. We don't use to refer to specific types of assistive technologies or adaptive strategies. We do have a requirement for instructors to have in-depth knowledge of Foundation Prerequisites. This is probably where it best fits.
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Favanan.url-protection.com%2Fv1%2Furl%3Fo%3Dhttps%253A%2F%2Fwai-curricula.netlify.app%2Fcurricula%2Fdesigner-modules%2F%2523foundation-prerequisites%26g%3DNjI4OTFmMjEzNTAxNDFkNw%3D%3D%26h%3DN2IwNDExMGEwYTAxZWIxZDE5OTIzYzY0ZjUyZGYxNzc4Y2E1MmNmOTU4ZmM1NTZhODI1MGM3OWM2NWJhY2Q2ZA%3D%3D%26p%3DYXAxZTpzaXRlaW1wcm92ZS1ldTphOm86MGIwZjMyOGYxMWY1ODhhZjQ5NjQ2NDJmMDQ4OWViYmU6djE6cDpO&amp;data=04%7C01%7CBrent.Bakken%40Pearson.com%7C21bec6c35cb047a2861908d9e666ada3%7C8cc434d797d047d3b5c514fe0e33e34b%7C0%7C0%7C637794150954708645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TCzQtALdaRYd9nqmbMaddTQ6iBKV4LJytvqX6jYFuRw%3D&amp;reserved=0
These modules cover How People with Disabilities Use the Web in more depth.

> 
> [ED-low] Module 5 > Images and Graphics > Topics to Teach > 
> Informative Images.  Consider using another more common phrase than "boilerplate images".  I am not familiar with this term - does it mean "basic", "common"
> or "default"?
> 
> - boilerplate descriptions that would then be completed and maintained through the development and authoring phases.
> 
> [ED-low] Module 7: Forms Design > Topics to Teach > Form Elements.
> Consider adding something related to the best practice of using semantic HTML in this case to this bullet point:
> 
> - identify related requirements for developers to write code for form 
> elements that programmatically identifies their purpose as well as their
> current state and value.    (The reason being that the code might work, but
> it could be a mix of aria and <div> when a radio button would be much easier to code and less work overall for developers).
> 
> Note - I believe this is referenced in the next area, "Teaching ideas 
> for Topic" -
> 
> "Show examples of different form elements and reflect on their purposes.
> For example, edit boxes, check boxes, radio buttons, and buttons. 
> Emphasize that non-standard uses of form elements can cause cognitive overload as well as compatibility issues with assistive technologies and adaptive strategies."
> 
> Consider defining "Non-standard uses of form elements".

This is more a developer's responsibility. We think that is covered there. This was just a cross reference for designers to be aware of the caveats that non semantic elements can cause, but we don't want to be very prescriptive.

--

Daniel Montalvo

Accessibility Education and Training Specialist W3C/WAI

Received on Friday, 4 February 2022 22:53:30 UTC