RE: [wbs] response to '[Curricula] Review of changes before Butterfly Approval'

Hey Hidde,

Many thanks for your feedback and for taking the time to go through the whole resource.

Please see some questions below.

> -----Original Message-----
> From: Hidde de Vries via WBS Mailer <sysbot+wbs@w3.org>
> Sent: miércoles, 9 de diciembre de 2020 16:15
> To: hidde@w3.org; dmontalvo@w3.org; shadi+eosurvey@w3.org
> Subject: [wbs] response to '[Curricula] Review of changes before Butterfly Approval'
> 
> The following answers have been successfully submitted to '[Curricula] Review of changes before Butterfly Approval' (Accessibility
> Education and Outreach Working Group (EOWG)) for Hidde de Vries.
> 
> >
> > ---------------------------------
> > Changes in Module 2: Menus
> >
> > ----
> > Please have a look at module 2 Menus specifically focusing on the
> > following:
> >  * Changed module and topic titles. Current proposal is:
> >      * Module 2: Menus
> >        * Topic: Menu Structure
> >        * Topic: Menu Styling
> >        * Topic: Fly-out Menus
> >        * Topic: Application Menus
> >
> >  * Reworded learning outcomes for module.
> >  * Reworded learning outcomes, teaching ideas, and ideas to assess
> > knowledge for topics "Menu Structure", "Menu Styling", "Fly-Out Menus"
> > and "Application Menus".
> > Is there anything from these changes that you would disagree with?
> > Please provide comments on the below box or open a GitHub issue
> >
> Comments:
> [developer hat on]
> 
> Generally, what I miss in this module is a clear explanation of whether and when to use ARIA-style menus. If I understand it correctly, most
> menus on websites are not application menus and should not be coded as such, but from this module it looks like they are a good choice.
> Would be good to have a examples of application menus vs not application menus. I feel most developers these days see what they're
> coding as an “application”, but this may be a different categorisation than what we mean in ARIA.
We could add more specific examples in the learning outcomes of this topic and assessment ideas along the lines of determining when and when not an application menu can be used based on certain specific scenarios. Anyway, I am still hesitant with this one as we now have a dedicated module for Rich Applications, where use cases for application menus may fit better. I will think about this and come up with a proposal.
> 
> > ---------------------------------
> > Changes in module 5: Forms
> >
> > ----
> > Please have a look at module 5 Forms specifically focusing on the
> > following:
> >  * Changed module and topic titles, as well as reorganized topic
> > contents. Current proposal is:
> >    * Module 5: Forms
> >        * Topic: Controls and Labels
> >        * Topic: Instructions
> >        * Topic: Notifications
> >
> >  * Reworded learning outcomes for module.
> >  * Content moved to topics "Instructions" and "Notifications" (was
> > previously under topic "Time Limits" now removed).
> >  * Reworded learning outcomes, teaching ideas, and ideas to assess
> > knowledge for topics "Control Labels", "Instructions", and
> > "Notifications".
> > Is there anything from these changes that you would disagree with?
> > Please provide comments on the below box or open a GitHub issue
> >
> Comments:
> One minor thing: I saw 'HTML element title' as a way to label form controls in certain situations… personally I was not aware there are
> cases where it is good to use, might there be something we can link to that explains it? Editor's discretion, it shouldn't take any of the
> succintness of the resource away, describing this in too much detail may be beyond scope, but wanted to note it regardless.
This is explained in the WAI Tutorials, Forms, Labeling Controls, Hiding Label Text.
https://www.w3.org/WAI/tutorials/forms/labels/
We link to that page in the teaching Ideas for topic "Controls and Labels", but it is true that we don't point specifically to that section. Do you think an explanation on the learning outcomes that these techniques are recommended only when the label text needs to be hidden would clarify?

> 
> >
> >
> > ---------------------------------
> > Changes in module 6: Custom Widgets
> >
> > ----
> > Please have a look at module 6 Custom Widgets specifically focusing on
> > the following:
> >  * Changed module and topic titles, as well as reorganized topic
> > contents. Current proposal is:
> >    * Module 6: Custom Widgets
> >        * Topic: Role Definitions
> >        * Topic: Accessible Names and Descriptions
> >        * Topic: States and Properties
> >        * Topic: Keyboard and Focus Management
> >
> >  * Reworded learning outcomes for module.
> >  * Content related to live regions partly moved to topic "States and
> > Properties", and partly expanded in new module 7, Rich Applications
> > (was previously under Topic "Live Regions" now removed).
> >  * Reworded learning outcomes, teaching ideas, and ideas to assess
> > knowledge for topics "Role Definitions", "Accessible Names and
> > Descriptions", "States and Properties", and "Keyboard and Focus
> > Interactions".
> > Is there anything from these changes that you would disagree with?
> > Please provide comments on the below box or open a GitHub issue
> >
> Comments:
> Under 'Learning outcomes' for role definitions, in 'WAI-ARIA authoring practices', Authoring and Practices should be capitalised.
Fixed.

> >
> >
> > ---------------------------------
> > Changes in Developer Modules overview page
> >
> > ----
> > Please have a look at Developer Modules overview page specifically
> > focusing on overall wording to outline the curricula contents.
> > Is there anything from these changes that you would disagree with?
> > Please provide comments on the below box or open a GitHub issue
> >
> Comments:
> Minor comment, editors discretion: feels like there are a lot of links on this page, maybe using a design patterns like the teasers on
> https://www.w3.org/WAI/planning-and-managing/ could help (Initiate, Plan, Implement, Sustain) for each of the modules.

Thanks for that suggestion. I don't fully understand it, as there are still links in those planning pages to the subsections they refer to, similarly as there are links to the modules and topics in the developers curricula overview page. Is it that the design aspects in the teaser component would make the page look cleaner, with more space or something?

Previously we did not have links to the topics, just to the modules. Would rolling back to just linking the modules improve the general perception?

> 
> > ---------------------------------
> > Additional comments
> >
> > ----
> > Please provide any other additional comments or suggestions you may
> > want to see addressed before we bring the curriculum back to the whole
> > EOWG for Butterfly Approval (Approval to publish) survey.
> >
> > Please provide comments on the below box or open a GitHub issue
> >
> Comments:
> I found two more very minor issues:
> 
> - in most modules, under “topics to teach”, the expand collapse all buttons are at the bottom of the section, while in the 'competencies'
> section, they are at the top, right underneath the introductory sentence
My understanding is that there should be just two expand all buttons on a page, one at the top and another at the end. We use to place the top expand all button just before the first individual expand button, and the bottom expand all button just after the last individual expand button.
What is exactly not working here for you?

> - for consistency: in module 1, it says ‘Topics to support the teaching sequence’  ending with a period, while before other lists on this page,
> these sentences end with a colon
Good catch! Fixed.

--

Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

Received on Monday, 14 December 2020 16:55:33 UTC