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

Hi Daniel,

Thanks for seeking clarification. My replies/comments inline as "AA2:".

Andrew
____________________________________
Andrew Arch
Principal Accessibility Consultant, Intopia
p: +61 (0)447 389 137 | t: @Intopia  @amja



-----Original Message-----
From: Daniel Montalvo <dmontalvo@w3.org> 
Sent: Friday, 16 October 2020 7:03 PM
To: Andrew Arch <andrew@intopia.digital>; shadi+eosurvey@w3.org
Cc: wai-eo-editors@w3.org
Subject: 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?

AA2: perfect :)

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

AA2: sounds good

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?

AA2: happy to leave this out at this stage. Maybe a note to traininers that occasionally CMSs force layout tables on users but that these should then be marked as "presentation".

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

AA2: :)

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

AA2: sounds ok

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

AA2: think I must have missed [Explain that use of placeholder for labels should be avoided as its value disappears once the user has entered a value.] in the Teaching Ideas part. However, it's doesn't disappear 'once the user has entered a value', it disappears on focus! There is also the contrast issues (though than can be designed for, it never is!).

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

AA2: that's fine

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

AA2: agree with the broad approach, but still think they need to go talk to the content author or designer if not provided with an guidance

AA2: maybe " identify informative, textual, decorative, functional, and complex images and now when to seek advice from the author or designer" - even a complex graphic can be purely decorative and the FED shouldn't have to make the call :(

> 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 &mdash; Students are asked to code descriptions for a set of given charts and graphics. Assess how students code descriptions for complex images.
]]

AA2: sounds fine

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

AA2: happy for it to be in custom widgets, just needs to be somewhere as so many SPA frameworks are being used these days with no appreciation of the accessibility issues that need to be dealt with.

--
Daniel Montalvo

Accessibility Education and Training Specialist W3C/WAI

Received on Friday, 23 October 2020 04:36:26 UTC