Re: [en] Curricula on Web Accessibility: A Framework to Build Your Own Courses

Hi Shadi,

#1 Yes. My comment is about the process.

I tried to comment on the page using the buttons at the bottom of the 
page and couldn't find anything appropriate. It needs a line edit, and 
githib isn't an efficient tool for that. It takes a lot of cognitive 
effort and time to see everything in context while switching between 
views or making changes using a format that’s not optimized for reading 
by people.

I'm glad you suggested switching to a Google doc –  that's much more 
appropriate as a line edit tool. I almost sent a Google doc instead, but 
I was trying to make the point that using the suggested methods did not 
work well given the stage of the document.

I did a line edit of the top third of the Curricula and Web 
Accessibility Page in a Google doc 
<https://docs.google.com/document/d/1zaI3bNJwSs7pMQgINmHYaNUwEq0z46Mi3-agIiiSUqs/edit#> 
so you can see it. I put the clean copy I'd previously done on top, then 
I went through and made the suggestions again on the original so you can 
see what I did.

I made edits for clarity and readability– I took out redundancy and 
improved the flow and language for readability. This is intended to be a 
sample to show that the language can be much clearer and suggest that 
after the committee gets through with substantive changes, there be an 
edit step before the text is laid out using a tool that allows for an 
proper line edit. I think this would make the process much more 
efficient. This is the process everyone’s copy goes through at every 
publication I’ve worked at.

Please take a look – I think this will make it clear that the process 
needs a line edit step in a proper line editing tool after the committee 
is done with substantive changes but before it is laid out on a webpage.

#2 – I didn't have any comment on preferences for style and presentation 
of pages, except as it relates to #1 – it's cognitively difficult and 
not efficient to do a line edit step after something's been styled, and 
then keep it styled.

#3 – I didn't have any comments about specific wording of the content as 
an invited expert, but as an editor. I'm trying to make it as readable 
as possible, rather than suggest substantive changes to the content. 
Thus the process suggestion.

Cheers,
Kim


On 4/8/2021 2:40 AM, Shadi Abou-Zahra wrote:
> Hi Kim,
>
> Many thanks for your feedback!
>
> Actually that page you are commenting on is not considered draft but 
> we are always happy to get feedback and suggestions for improvement.
>
> As I understand, you have three main comments:
>
> #1. Overall process for collaborative development and commenting
> #2. Preferences for the styling and presentation of the pages
> #3. Preferences for the specific wording of the content
>
> The first two points relate to the EOWG process and WAI Website Style 
> respectively, and are outside the scope of this WAI Curricula project. 
> I'm copying Shawn Henry who is conveniently primary EOWG Staff Contact 
> and WAI Outreach Coordinator, and may have further thoughts on this.
>
> As to the third point, could I ask you to provide rationale for each 
> suggested change? Typically we ask people to provide such comments:
>
> - Current text
> - Suggested text
> - Rationale for change
> - Indication of priority (objection, strong suggestion, nice to have...)
>
> The reason for this is that everyone has different wording preferences 
> and we need to find a middle-ground between the different 
> perspectives. I'm sure you will know this from writing Techniques and 
> Understanding documents, someone always has a different wording 
> preference but you'll need to draw a line somewhere. This text has 
> undergone fairly extensive review and revisions already, so it would 
> be good to have substantial comments (ie. technical flaws or otherwise 
> high-priority issues) before re-opening discussions that the group has 
> already closed.
>
> It would be most helpful if you can provide your feedback directly as 
> GitHub issues [1] but we welcome other formats too. For example, you 
> could put your comments in a Word or possibly Google doc, and send the 
> link. Of course the format used must be accessible. Please note that 
> screenshots are not accessible. As noted, please include rationale for 
> your suggestions, so that the group can better consider your input.
>
> [1] https://github.com/w3c/wai-curricula/issues/new
>
> Many thanks,
>  Shadi
>
>
> On 08/04/2021 00:21, Kim Patch wrote:
>> Greetings. I took a look. I like the contents – I think with a good 
>> edit the language can be made clearer and tighter.
>>
>> My first very strong suggestion is about this process –I think it 
>> would be much more efficient to take the text through an edit process 
>> using an editing tool like Google docs that has a track 
>> changes/suggestions feature rather than publishing draft language. 
>> This would allow more people to efficiently suggest changes and would 
>> allow whoever's making the changes to see each change and quickly 
>> accept or reject it.
>>
>> Here's some suggested language – just for the first part of the page. 
>> I cut-and-paste into an editor to make the changes, but cutting and 
>> pasting back into this email lost the formatting.
>>
>>     Curricula on Web Accessibility
>>     A Framework to Build Your Own Courses
>>     Summary
>>     This is a resource to help teach accessibility. You can use it to
>>     develop courses or include accessibility in existing courses.
>>
>>     Page Contents
>>     Using the Curricula
>>     Contents
>>     Curricula Modules
>>     Structure and Terminology
>>     Essentials for Teaching Accessibility
>>     Using the Curricula
>>
>>     This framework for teaching accessibility contains four modules that
>>     help teachers show students how to make software accessible to
>>     everyone.
>>
>>     The Foundation module covers broad accessibility concepts that
>>     anyone in IT will benefit from. The Developer, Designer, and Author
>>     modules cover skills for developers, designers, and content authors.
>>
>>     Teachers can mix-and-match from these modules to develop courses on
>>     digital accessibility, or to include accessibility in courses such
>>     as programming and graphics design. Teachers can combine modules to
>>     create lightweight or in-depth training on accessibility. The
>>     modules don’t prescribe duration, effort, or accreditation.
>>
>>     Some example uses:
>>     A faculty lecturer might use parts of the Foundation, Developer, and
>>     Designer modules to teach accessibility to computer science 
>> students.
>>     An accessibility professional might tap the Foundation, Developer,
>>     Designer, and Author modules to create an accessibility training 
>> course.
>>     An employee training coordinator might use the curricula to assess
>>     course content offered by other providers.
>>     A procurer might base requirements in a training Request for
>>     Proposals (RFP) on parts of the curricula.
>>     A hiring manager might use the modules to compare the competencies
>>     assessed for certificates.
>>
>>     Contents
>>
>>     The Foundation and Developer modules are available now. The Designer
>>     and Author modules will be available in 2021.
>>
>> *
>> **Here's a screenshot that lets you see the edited text a bit better 
>> with basic formatting:
>>
>> *
>>
>>
>> *Here's a screenshot of the ORIGINAL TEXT**for comparison – notice 
>> it's considerably longer:**
>> *
>>
>>
>> -- 
>> ______________________________________
>>
>> Kimberly Patch
>> (617) 325-3966
>>
>> patchontech.com
>> @patchontech
>> scriven.com/kimpatch
>> ______________________________________
>>
>>
>

-- 
______________________________________

Kimberly Patch
(617) 325-3966

patchontech.com
@patchontech
scriven.com/kimpatch
______________________________________