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

Hi Daniel,

Thanks for the quick response. My comments are inline.

On Thu, 17 Dec 2020 at 12:50, Daniel Montalvo <dmontalvo@w3.org> wrote:

> 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?
>

I believe "rely on structures" makes it understandable. I'm okay with the
change.


>
> > - 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?
>

I think that would help. My proposal would be to have the buttons before
the first section and after the last section to make it even clearer that
they apply to all sections. However, I'm not totally happy with my
proposal, because the buttons after the last section would be far (2
sections) away from the last expandable/collapsible section.


>
> > > ---------------------------------
> > > 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"
>

That makes it clear for me. I rather prefer this version.


>
> > 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"
>

Great!


>
> > 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?
>

That suggestion would make focus indicators relevant for the module,
indeed. I believe that, not only that works, but also has the advantage to
explicitly include such important concepts as orientation, navigation and
links.


>
> > > ---------------------------------
> > > 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?
>

I still think we shouldn't be listing responsibilities for other roles in a
curriculum. I agree that we should link to them when we have the other
curricula ready.
However, if we want to highlight some of the responsibilities that are
shared between roles, my suggestion would be to do that: make it clear that
they are shared. Current phrasing states "recite related requirements".
"related" does not mean that they are shared, only related. If we update to
shared requirements, then I won't argue against keeping the mentions.


>
> >
> > >
> > >
> > > ---------------------------------
> > > 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?
>

Yes, that would solve this one too.


>
> > > ---------------------------------
> > > 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:
> ...
> ]]
>

Yes, I feel that is better.


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

Thanks for all the hard work, Daniel!

Cheers,
Carlos


>
> --
> Daniel Montalvo
>
> Accessibility Education and Training Specialist
> W3C/WAI
>
>

-- 
*Carlos Duarte*
LASIGE, Faculdade de Ciências, Universidade de Lisboa
Web: https://www.di.fc.ul.pt/~cad/
Twitter: @carlosapaduarte