RE: [wbs] response to 'Curriculum "Developing Accessible Content" -- Monkey Review'

Hey Andrew,

Thanks for your feedback.

Please see some follow-up in-line questions and suggestions for change. If you want to see these changes in context, you can visit the live draft at
https://deploy-preview-273--wai-curricula.netlify.com/curricula/developing-accessible-content

There you can use the nav bars to go from module to module.

> > ---------------------------------
> > Module 4: Tabular Information
> >
> > ----
> > Please focus on Module 4: Tabular Information.
> >  * Are all points covered - is anything missing?
> >  * Is there anything in there that should not be in there?
> > You can comment below or leave a GitHub Issue about Tabular Information.
> >
> Comments:
> Need to also consider that a student should know:
> 1. Sometimes the mark-up of complex tables may not be obvious and the person coding the table will need to ask the table compiler about
> the relationships (and if the table can be split into a number of simpler
> tables)

Added learning outcome for module:
"summarize related requirements for authors and designers to provide information about the relationships between header and data cells in complex table cells"
This is to make clear that the developer may or may not know about these relationships and, if they don't, they can expect further information from authors and designers.
Is this what you expected here? Any further suggestion to make this clearer?

> 2. What to do with a table used for layout if that is the only layout choice (eg in an HTML email) so it's but treated as a data table by screen
> readers What about the content or visual designer - what is their knowledge requirement / learning outcome? (OR conversely, what should
> the FeD expect to receive from these designers to assist them in accessibly coding different tables?)

This module is about tabular information, so layout tables seem a bit out of scope. I see your point that some reference to these should be made, and added a learning outcome for topic "Simple tables":
"summarize related requirements for designers and content authors to use CSS techniques for avoiding table layout designs"

As per what to do when you **have to** use a layout table in an email, I don't think there is a clear solution apart from not to use them. Sometimes these decisions are made at an Authoring Tool level, and there is little that can be done by default to prevent this behavior unless the authoring tool vendor fixes it. There are some Ats that present the contents of a layout table as plain text, some others don't. How would you expand the current guidance we are providing for this specific use case?

> > ---------------------------------
> > Module 5: Forms and Input Elements
> >
> > ----
> > Please focus on Module 5: Forms and Input Elements.
> >  * Are all points covered - is anything missing?
> >  * Is there anything in there that should not be in there?
> >  * Do you agree with the overall topic structure?
> > You can comment below or leave a GitHub Issue about Forms and Input
> > Elements.
> >
> Comments:
> 2.5.3 Label in Name is missing from Instructors Expertise

Good catch! It is now included.

> Students should be able explain the relative merits of label/for, title, and aria
> attributes and when each might be appropriate (Student learning
> outcomes)

I have extended these learning outcomes for topic "Form labels":
[[
* code labels and input fields associations using:
  * the HTML attribute `for` (when an explicit association is needed)
  * the WAI-ARIA attributes `aria-label` or `aria-labelledby` (when the label text needs to be visually hidden)
  * the HTML element `title` (when the label text needs to be visually hidden)
]]
Is this what you were missing here?
> Students should understand why 'placeholder' should not be used
I don't understand this enough. We have this in the teaching ideas.
[[
...
Mention that `title` and `placeholder` may not be well supported by some assistive technologies. Explain that the value of the `placeholder` disappears when the user enters a value, so essential instructions need to be provided using the other described methods.
]]
Do you think we should be providing this information in the learning outcomes?

> Students should understand the value of "save" & "continue" for users,
> esp for some people with cognitive impairments, people who might need to seek advice on an aspect, people who might need to find
> information, etc
I have added these to the learning outcomes for topic "Form Instructions"
"summarize related requirements for designers to provide mechanisms that consolidate already entered data"
Does it address your concern?

> > ---------------------------------
> > Module 3: Images and Graphics
> >
> > ----
> > Please focus on Module 3: Images and Graphics.
> >  * Are all points covered - is anything missing?
> >  * Is there anything in there that should not be in there?
> > You can comment below or leave a GitHub Issue about Images and Graphics.
> >
> Comments:
> Is it the role of a FeD to "identify informative, textual, decorative, functional, and complex images"? Shouldn't the designer (graphic,
> content,
> etc) identify these and provide instruction to the Dev?

Definitely it is not the role of a dev alone, there needs to be others involved. We had a discussion within the Task Force. Before we played with "distinguish between" and we tried to soften that idea by replacing "distinguish" with "identifying". We try to convey that the developers need to be aware that these types of images exist, but we also acknowledge that other roles are the ones in charge of providing adequate descriptions based on the image types.
Do you agree with this approach? Do you have further suggestions as to how this should be worded?

> Complex Image assessment "Students are shown charts and graphics without descriptions and are asked to provide them" - personally I
> don't think this is a Dev's job - this info should have been provided to them by the image preparer.

This assessment reads now:
[[
Practical — Students are asked to code descriptions for a set of given charts and graphics. Assess how students code descriptions for complex images.
]]

> 
> 
> >
> >
> > ---------------------------------
> > Module 2: Navigation and Menus
> >
> > ----
> > Please focus on Module 2: Navigational Menus.
> >  * Are all points covered - is anything missing?
> >  * Is there anything in there that should not be in there?
> > You can comment below or leave a GitHub Issue about Navigational Menus.
> >
> Comments:
> Not sure, but should SPA navigation come in here?
Conceptually, I see this more in the "Custom Widgets" module.
- There is not standard native HTML equivalent for SPA.
- Custom scripts need to be developed to support this and to make it accessible.
I see SPAs, then, as another of the many custom widgets we deal with in module 6. 
Happy to discuss further anyway.


--
Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

Received on Friday, 16 October 2020 08:02:52 UTC