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

Hey Kris Anne,

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:
> Struggle with the idea of teaching people about table summary to tell them that it is an obsolete element in HTML 5.  Others may be fine
> with it, so I will go with the majority decision.

We did discuss what to do with obsolete or deprecated elements/attributes in the Task Force. We went with the idea of qualifying why we are mentioning them and when they should be used. I see your point that the current phrasing of this is ambiguous. I have qualified it a bit.

Topic "Table Summaries and Descriptions"
Learning Outcomes
"the HTML attribute `summary` (recommended for fallback purposes)"
Teaching Ideas
"Explain the use of the attribute `summary` to provide people using a screen reader with detailed information about the structure of complex tables. Emphasize that it is obsolete according to the HTML5 specification and should, therefore, be used with caution. Its usage is only advisable for fallback purposes. [...]"

Would you feel more comfortable with this change?

> > ---------------------------------
> > 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:
> At any point, do we recommend using AT to show users how poorly structured forms can cause issues?  With AT or even with something like
> Auto-fill?  I know Auto-fill is a touchy subject, but its helpful for users with different cognitive needs and if you try to fill in information
> automatically, and forms aren't labeled properly, it could cause information to be incorrectly populated.

I have broadened scope of the following idea to assess knowledge for module.
[[
Practical — Students are guided to fill in form controls using mechanisms that assistive technologies provide to move to next and previous form control or to show all form controls in an isolated list. Assess students' knowledge of mechanisms of assistive technologies to interact and fill in form controls.
]]
It now focuses on guiding students to fill in form controls using Ats. I think this covers your point. This of course can apply to the different types of form controls that are discussed through the module.

> > ---------------------------------
> > Module 6: Custom Widgets
> >
> > ----
> > Please focus on Module 6: Custom Widgets.
> >  * 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 Custom Widgets.
> >
> Comments:
> are we encouraging people to create custom keyboard shortcuts for their widgets?  Or how to use existing keyboard shortcuts?  we have
> had a few developers want to create custom keyboard shortcuts lately and wonder the affect that has in conflicting with AT if a user is a
> keyboard use and a user of other AT that has keyboard shortcuts built in.

Our intention here is to tell the students that they can add keyboard shortcuts but, if they do, they have to avoid keyboard conflicts with browsers and Ats. I think we should neither encourage or discourage students from creating keyboard shortcuts in their custom widgets, but definitely we need to explain them what their pros and cons are. Do you have further ideas to clarify this more?

> > ---------------------------------
> > Module 1: Structure and Semantics
> >
> > ----
> > Please focus on Module 1: Structure and Semantics.
> >  * 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 Structure and
> > Semantics.
> >
> Comments:
> Do we ever, in any of the modules, encourage the students to use HTML Validators to verify their code is properly formed?  We see a lot of
> issues that just trace back to poorly formed code.  Just wondering since I know W3C has an HTML validator.

In my view, that would be a little bit out of scope. Code validation is no longer an accessibility requirement since WCAG 2 (only parts of it in 4.1.1 are). Happy to discuss this further anyway.

--

Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

Received on Friday, 16 October 2020 08:51:35 UTC