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://wai-curricula.netlify.app/curricula/designer-modules/#foundation-prerequisites
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 Wednesday, 2 February 2022 14:46:16 UTC