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

Hey Kevin,

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 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:
> I think there is scope to include something on understanding why custom widgets prove problematic and highlighting the risks in using some
> attributes, such as 'role'

Probably most of this was not coming through clearly in the current iteration. I have reworded learning outcomes for module and topic. Now they read.

[[
Learning outcomes for module

Students should be able to:

* identify standard and custom widgets based on accessibility semantics and determine when to use each of them
* explain how accessibility properties, keyboard and focus interactions, and live regions enable people with disabilities to operate widgets
* code keyboard and focus interactions when necessary 
* code accessible names, descriptions, roles, and states
* mark up live regions to notify users of content updates
* code accessible buttons, carousels, sliders, tabs, treeviews, and other widget roles described in the [WAI-ARIA Widget Roles](https://www.w3.org/TR/wai-aria-1.1/#widget_roles)

[...]

Learning Outcomes for Topic "Semantics and Widget Roles"

Students should be able to:

* determine how to use standard and custom widgets based on accessibility semantics
* explain what element roles mean in the context of Web accessibility
* explain how WAI-ARIA attributes override semantics of the elements they are applied to
* explain how roles allow people using assistive technologies to get information about widget types
* code widgets using standard HTML elements that convey semantic information to the extent possible
* code necessary roles when standard HTML elements do not provide the necessary semantic  information
]]

Does this address your points here? Any other ways in which you think this could be better communicated?

> > ---------------------------------
> > 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:
> There are a number of points that suggest WAI-ARIA i native elements can't be used. I wonder if there might be a need to include something
> of learning outcome around understanding why this can be problematic and what is involved in taking this approach.

I have included a new learning outcome for module

* identify the benefits of using HTML native elements to the extent possible for broader compatibility with assistive technologies and adaptive strategies

That focuses on the general preference of HTML over ARIA. Instead of saying Aria can be dangerous, we say HTML native markup is preferred. Are you comfortable with this wording?

> > ---------------------------------
> > Additional comments
> >
> > ----
> > Use the space below to include any additional observations or concerns
> > you would like to see addressed.
> > Remember: This is the last review before the approval to publish survey.
> >
> Additional Comments:
> I wonder if there is a slight elephant in the room: many front end developers don't code in HTML but use a framework such as React. This
> means they aren't building pages in the ways outlined in these courses and may consider it not relevant to them. Do we need to
> acknowledge this in some way?

I am not sure if I understand correctly. Is it the word "Code" that is around in many learning outcomes that may be problematic? Would it help if we acknowledge that these coding techniques that we provide can (and should) also be implemented at a framework level for the framework to produce accessible code?

> May be can of worms that I have opened previously but, are these all optional topics? Or are they suggested topics? If they are all optional
> then what is necessary?
Good point. These are now "Topics to achieve the learning outcomes" as topics are all necessary to support the teaching sequence.

--

Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

Received on Tuesday, 20 October 2020 09:13:32 UTC