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

Hey Kevin,

Thanks for such a thorough review and for these valuable comments.

Please see my proposed updates for your other comments.

> -----Original Message-----
> From: Kevin White via WBS Mailer <sysbot+wbs@w3.org>
> Sent: miércoles, 16 de diciembre de 2020 10:48
> To: kevin.white@gov.scot; dmontalvo@w3.org; shadi+eosurvey@w3.org
> Subject: [wbs] response to '[Curricula] Review of changes before Butterfly Approval'
> > ---------------------------------
> > General Changes
> >
> > ----
> * "recite" isn't really the right word. I think the phrase is that "students should know related requirements..." but that doesn't quite fit with
> the opening statement for the lists. Perhaps, "describe" would be good or maybe better would "detail".

After discussed within the TF, we plan to use "describe"

> 
> * "Topics to achieve the learning outcomes" seems to be "Topics to support the teaching sequence". The former is certainly better than the
> latter.

We are rolling back to the former.

> * [Minor] The assessments include the phrase "Students are guided to use..." it seems a bit... off. If it is an assessment students wouldn't be
> guided in anything. Would the be asked to demonstrate?

That was in response to comments that using some assistive technologies is not really the key learning objective plus it could be challenging and discouraging for some. The idea that they are not required to use it alone but with some kind of guidance/supervision. 

What about:

"Students are supervised/monitored/ while using an assistive technology to...

> > ---------------------------------
> > [New] Module 7: Rich Applications
> >
> * ", which may each be individual widgets" - not sure what this adds other than a bit more of a challenge to parse the sentence.  I think it
> could be better explored in the detail than introducing it in the topic introduction.

What about removing that part from the introductory paragraph and adding that to the existing learning outcomes? It would look like:

[[
Refer back to [Module 1: Page Structure](/curricula/developer-modules/page-structure/) and explain the importance of proper structures and semantics within applications just as within less dynamic web pages. Demonstrate how assistive technologies rely on clearly identifiable sections and regions. Explain how content that is dynamically generated, for example through JavaScript, needs to be properly reflected in the DOM.

Learning outcomes
* code applications and dynamically generated content with appropriate mark up structures and semantics, including:
...
 * individual widgets, including menu bars, form controls, and custom widgets

]]

> 
> * There seems to be a lot of repeated content between Structure and Relationships and Module 1. I am not sure what the learning outcome
> really is or how this relates to RIA? Not saying that it isn't necessary just a bit unclear as to why it is being repeated.

This tries to emphasize how these notions would apply not just to static websites or regions but to complex and rich applications. We somehow counted on the fact that this would be a little bit repetitive compared to module 1, but still think it would be useful to remark the need to take structure and semantics into account for rich applications as a whole. Any further suggestions on how to reduce this repetition? Things that should not be in this topic, for example?

> 
> * First teaching idea seems to be using a disclosure widget as the example for navigation. I wonder if this is too limiting and doesn't
> illustrate how structural elements and regions help navigation.

What about:

[[
Demonstrate navigation between several widgets in an application using assistive technologies, such as text-to-speech and voice interaction. Explain how these components show or hide depending on user action. For example, when the user goes to the menu bar, the main text area, or a toolbar, the other application widgets may be hidden or greyed out. Emphasize that these states need to be programmatically marked up by updating, adding, or removing the corresponding elements from the DOM.
]]

This broadens the scope, it is not just about menus or disclosures, but really about general navigation between the different widgets of an application. Would that work?

> * Use of aria-hidden - I have seen this being used to present two different sets of content; one visually but not in the accessibility tree, and
> one non-visually but in the accessibility (using e.g. sr-only CSS). Worth mentioning?

What about:

[[
* Discuss different mechanisms to hide content from view, from the accessibility tree, or from both, such as the WAI-ARIA attribute `aria-hidden`, the HTML attribute `hidden`, or the CSS property `display:none`. Explain that code needs to reflect the current state of each of the application widgets.
]]

> 
> * Structure and Relationships ideas to assess asks students to code for updates, but the learning outcomes don't actually cover this - there
> may be a need for something specific along the lines of "code applications to update structure and/or semantics in response to user action"

I am not sure about the "based on user action" part. Sometimes updates may be beyond the user control.

What about:

"write code for updating applications and dynamically generated content with appropriate markup structures and semantics, including:"
> 
> * Topic: Keyboard and Focus Interactions - is this more about "Keyboard and Focus Management"?

It is. But we tried to provide a different title here as this is building on "Keyboard and Focus Management" from Module 6, but from the perspective of an overall application instead of from a custom widget.
Is it a problem to have "focus management" for "custom widgets and afterwards "focus interactions" for "rich applications"?

> * Is there a need to add a learning outcome around focus management for inline error messages on form submission?

What about:

[[
ensure that the focus is placed appropriately when inline error messages are generated for application form controls
]]

> * "Mention that setting focus to the most relevant place in a rich application is a shared responsibility among different team members:
> designers and developers" - It may not be apparent what each responsibility is. Maybe something more explicit like (sorry, wording may
> need work) "Outline the designer responsibility to describe the next logical interaction and developer responsibility to ensure that focus is
> managed accordingly".

What about:
[[
... Mention that defining keyboard and focus interactions is a designer's responsibility, whereas coding such interactions is a developer's responsibility.
]]

> * "Demonstrate the use of mechanisms to obtain information about the available keyboard shortcuts" - is this about demonstrating ways to
> communicate this rather than ways that it might be found? As it is written it hints that there are some standard ways that you can find out
> about keyboard shortcuts in applications. New one on me if there is such methods?

Thanks for this. Proposed rewording is:

[[
Demonstrate the use of mechanisms to communicate information about the available keyboard shortcuts in rich applications, such as web-based email clients, spreadsheets, and word processors. Explain that when an application makes extensive use of non-standard keyboard shortcuts, a mechanism that provides users with information about these shortcuts is necessary. Mention that  coding these messages is a developer's responsibility, whereas providing them is a designer's responsibility.
]]

> * "Explain that specific focus treatment should be applied to the contents that are not part of the modal dialog as long as it is displayed so
> that they are not reachable using the keyboard" - not sure what this is getting at.

This tries to communicate that items that do not belong to the dialog or modal should not be focusable. Maybe we should say it more clearly, like in:

* Demonstrate accessible and inaccessible modal dialogs. Emphasize how focus remains within the boundaries of the dialogs when they have been coded appropriately. Explain that the contents that are not part of the modal dialog should not be focusable as long as the modal dialog is displayed.

> * "identify and code status messages that may not originate from any particular widget or part of the application" - not sure why or where
> such messages would come from then?

This is a typo. Will change to "may originate".

> * Is there something missing in notifications to discuss the different specialized live region roles such as log, status?

I took a pass on these learning outcomes and added them as follows:

[[
...
* identify and code status messages that may originate from any particular widget or part of the application using the WAI-ARIA `role="status"`
* code alerts using WAI-ARIA `role="alert"` and identify situations in which it is appropriate to interrupt users
* code messages containing non-essential information using the WAI-ARIA `role="log"`, or `role="marquee"`,
 * code numerical counters using the WAI-ARIA `role="timer"`
...
]]

Would this work for you?

> 
> * Not sure the first teaching idea in notifications is that great. If the goal is to explore live regions being used to indicate progress of change
> then I think an example like an address look up or making a data request from another source would be more appropriate.

Changed to.

[[
Demonstrate interaction to request data from applications, such as making a data request for new emails or operating an address lookup. Explain that these data exchanges could be skipped by users of assistive technologies if they are not marked up correctly. Emphasize that live regions to indicate that new data is being loaded or that there is a waiting time should be provided so that users are aware of what is going on.
]]

Would that work for you?

> * The second teaching idea in notifications mentions modal windows and alerts on warnings which would require interactions. I don't know
> that I would use a live region in this case as I don't just want the user to be informed, I would need them to do something - so it would be a
> modal dialog with an active choice. What about confirmation messages as a teaching idea or a chat bot... oh, those are all the rage!
> 
> * Again, not sure I would code a quit prevention using a live region - I would do it with a modal and focus management. What about
> students coding a progress bar?

Changed to:

[[
Compare accessible and inaccessible examples of applications confirmation messages warning about critical errors that can cause data loss, or progress bars indicating timeouts. Explain that, when these messages are populated, these should be given high priority in the list of the live regions so that users can take action to avoid data loss or to solve the problem.
]]

Would that work?

> * Not sure what the second assessment idea is at all

This intends to cover single page applications. When you change to a different view or page, you need to indicate this change to assistive technologies. I have reworded it as:

[[
* Practical &mdash; Students are presented with a Single Page Application (SPA) with several views and are asked to code the messages for assistive technologies to indicate what is the currently loaded view. Assess students' knowledge of how to use polite live regions to provide individual notifications based on the currently
]]

Would that work for you?

> > ---------------------------------
> > Changes in Module 1: Page Structure
> >
> * "explain how headings, including their rank levels, are used by different types of assistive technologies, such as text to speech, and
> adaptive strategies, such as custom stylesheets, to allow people with disabilities to understand and navigate the content" - too many 'such
> as' structures.
> Possibly "explain how headings and their rank levels are used by different types of assistive technologies and adaptive strategies, such as
> text to speech or custom stylesheets, to allow people with disabilities to understand and navigate content". Of just dump the 'such as ..'
> entirely.

I slightly prefer:

"explain how headings and their rank levels are used by different types of assistive technologies and adaptive strategies, such as
text to speech or custom stylesheets, to allow people with disabilities to understand and navigate content".

> * "explain how properly coded page regions can be presented in different ways, including being read aloud using text-to-speech
> technologies, with custom or without any styling, and in different screen and text sizes" - this is used in a couple of the learning outcomes. I
> think I get what it means but I might struggle to actually teach to that. Might benefit from a clearer outcome?

What about:

"explain how properly coded [...] can be presented in different ways; for example, read aloud using text-to-speech
technologies, rendered using custom styling, and displayed in different screen and text sizes"

> * "code the primary language of web pages to allow correct processing by assistive technologies" - correct processing or correct
> pronunciation?

It is true that pronunciation is the most obvious thing we are referring to here, but there is also braille table choosing, or even left-to-right versus right-to-left languages.
What about "correct interpretation".

> * "code distinguishable focus indicators, for example by using the CSS :focus selector" - this seems out of place here but I am not sure
> where else it might go? - actually, reading the topic introduction I am beginning to think that the topic title could benefit from a change. It
> seems to be a catch all around orientation and navigation rather than composition. I think of 'composition' as the action written word.

We are planning to broad the scope of this topic a bit more.

- It would be titled "Page orientation and navigation"
- We will mention links specifically as elements that allow for orientation and navigation.

Preview is at:
https://deploy-preview-273--wai-curricula.netlify.app/curricula/developer-modules/page-structure#topic-page-orientation-and-navigation

---

I assume your comments for module 2-6 are addressed in GitHub--

Thanks.

Best.

--
Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

Received on Thursday, 7 January 2021 09:31:55 UTC