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

Hey Carlos,

Thanks for getting through  this whole survey.

Please see some follow-up comments and questions below.

> -----Original Message-----
> From: Carlos Duarte via WBS Mailer <sysbot+wbs@w3.org>
> Sent: martes, 15 de diciembre de 2020 21:12
> To: caduarte@campus.ul.pt; dmontalvo@w3.org; shadi+eosurvey@w3.org
> Subject: [wbs] response to '[Curricula] Review of changes before Butterfly Approval'
> >  General Changes
> - I'm not sure about the "recite" change. To me recite implies committing to memory so that later it can be repeated word by word. I don't
> think we want to ask a developer to know, word by word, the requirements for designers, for example. I agree that summarising did not
> stress enough the importance of being aware of those requirements. But recite seems to me to be on the opposite end of the spectrum,
> and I believe something in between would be better. I would prefer to use "explain" because that would mean the student developer
> understood the requirements for designers, which is a lot better than reciting them (which does not imply understanding).
> 
> - Regarding the "Topics to achieve the learning outcomes" change. I prefer the suggested use of "Topics to achieve the learning outcomes".
> However, the current preview uses "Topics to support the teaching sequence". This implies there is a sequence, but that sequence is not
> clearly presented.
> 
We will need to further discuss these two in the TF. I will work on proposals on those to discuss.

> > ---------------------------------
> > [New] Module 7: Rich Applications
> 
> - In the first bullet of the introduction, what does it mean "demonstrate how people with disabilities use structures"? Removing "use
> structures,"
> would make the whole sentence clearer.

Down below in the email I suggest we use "rely on" instead of "use". Would the sentence be easier to understand if it said, "rely on structures" instead of "use structures"? Or does the word "structures" in this context still jump out at you?

> - The "Expand All Sections" and "Collapse All Sections" buttons are being applied to all sections inside the module and not just the
> subsections of the section they are presented in. Given they appear below the "Competencies" section I was expecting them to apply just to
> the "Students"
> and "Instructors" subsections. But they are expanding and collapsing also the "Topics to Teach" subsections. (this applies to the other
> modules also)

Currently, due to how this component is designed, it expands all the sections that are on the page. It is not possible to use it several times for independent expandable sections such as what we have here. What if we put the top expand and collapse just before the heading "Competencies"? Would that help understand that the button will actually expand all sections (competencies and topics to teach) down the page?

> > ---------------------------------
> > Changes in Module 1: Page Structure
> - I have concerns about 3 entries in the learning outcomes for module.
> First is the "mark up page meta-information to facilitate identification and processing". It is not clear to what "facilitate identification and
> processing" refers to. I'm identifying and processing what?

This is to point out how a single page can be identified within a set of pages via its meta-information: title mainly. And also, about how meta-information allows processing (pronunciation) of different languages by assistive technologies. So, what about:

"mark up page meta-information to facilitate page identification and accurate pronunciation of page and content language"

> Second is the "outline the benefits of using HTML native elements for
> compatibility with assistive technologies and adaptive strategies". There is an implicit comparison here between native elements and
> elements with ARIA and scripting. I think this should be made explicit.

Good suggestion. What about:

"outline the benefits of using HTML native elements for compatibility with assistive technologies and adaptive strategies, as opposed to non-standard elements that rely on WAI-ARIA and scripting"

> Third is the "mark up content so that it has a distinguishable focus
> indicator". I don't think this belongs in this module. The module is about page structure, and I believe this is not the appropriated place to
> talk about focus indicator, especially because most structures discussed in the module won't even be focusable.

Where would we introduce these focus indicators then? We have been playing with several possibilities, but the problem is that after this module we dive into singular components: menus, images, tables, forms. Focus indicators apply to them all, and wherever we place these references, they would still either be off or needed elsewhere. What if we broadened the scope of this module's last topic and include orientation, navigation, and references to links there? Would it be OK for you?

> > ---------------------------------
> > Changes in module 3: Images
> >
> > ----
> I don't disagree with any of the changes in this module, but I believe including an additional item in the "ideas to assess knowledge" for topic
> "Complex Images" would be beneficial. The item would be practical and focus on using SVG to provide graphics. Current ideas ask to have
> students coding descriptions and writing CSS. By "pushing" for having images in SVG we would be "pushing" for more accessibility.

Will do.

> > ---------------------------------
> > Changes in module 4: Tables
> >
> - This module makes use of a concept that I haven't found in other modules when itemising assistive technologies: "provided by speech and
> mainstream technologies". I have to say I don't really know to what you are referring to when using "mainstream technologies" in this
> context. (it also appears in the Forms module)

I will harmonize and mention "assistive technologies and adaptive strategies" as we do in other modules.

> - In the "Simple Tables" topic, the last item in the "Teaching Ideas" list is about different concepts: alternative rendering of data tables, and
> layout tables. I suggest to split it into 2 items in this list.

Will do.

> > ---------------------------------
> > Changes in module 5: Forms
> - In the topic "Instructions", the last of the "learning outcomes" list has a nested list of what are requirements for content authors and
> designers. I don't think this level of detail is needed here, specially since it doesn't have related teaching ideas.
> 
> - In the topic "Notifications" I have a similar comment regarding the level of detail of requirements for content authors and designers.

I think some mention of those responsibilities is worthy. This is an area of work where both roles need to work together to produce accessible instructions and notifications. Would it be better if we try to include such mentions in the top-level list and get rid of the nested lists? Or is it those mentions themselves that you think we should get rid of?

> 
> >
> >
> > ---------------------------------
> > Changes in module 6: Custom Widgets
> >
> - The first of the two items in the introductory list (i.e. the courses on this module should) doesn't seem to make much sense. People with
> disabilities don't use properties, states, focus interactions (at least) these to interact with custom widgets. The custom widgets are the ones
> that make use of properties, states, etc. to make the custom widgets accessible, so that people with disabilities can interact with them.

This has to do with the above comments in module 7. Would changing from "use" to "rely on" address the issue?

> > ---------------------------------
> > Changes in Developer Modules overview page
> 2 - The list of objectives for the courses feels very theoretical (introduce, demonstrate and explain). I feel we need some practical
> keywords, like "courses that teach accessible coding"

What about:

[[
* demonstrate and explain how accessible coding enables people with disabilities to use the Web
* teach accessible markup and coding techniques around:
...
]]

I will implement all other suggestions from your comments in this question: reordering or paragraphs and removal of "following".

--
Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

Received on Thursday, 17 December 2020 12:50:37 UTC