- From: Daniel Montalvo <dmontalvo@w3.org>
- Date: Wed, 7 Sep 2022 10:33:50 +0200
- To: <wai-eo-editors@w3.org>
- Message-ID: <019601d8c294$8fc10690$af4313b0$@w3.org>
From: Sarah Lewthwaite <S.E.Lewthwaite@soton.ac.uk> Sent: Wednesday, September 7, 2022 10:30 AM To: Daniel Montalvo <dmontalvo@w3.org> Subject: Re: Review of Content Author Modules Hi Daniel, Thank you for the response. And these immediate updates and clarifications. Yes, I'm happy for my comments to be publicly archived. I completely understand the issues about cross-role working and anticipating workflow etc. I think what you have proposed helps, as you say, in the broader sense on this issue. Please do progress with the publication approval survey! Best wishes, Sarah From: Daniel Montalvo <dmontalvo@w3.org <mailto:dmontalvo@w3.org> > Date: Wednesday, 7 September 2022 at 08:51 To: Sarah Lewthwaite <S.E.Lewthwaite@soton.ac.uk <mailto:S.E.Lewthwaite@soton.ac.uk> > Subject: RE: Review of Content Author Modules CAUTION: This e-mail originated outside the University of Southampton. Dear Sarah, Thank you very much for providing these comments in such a short turnaround. Typos, capitalizations, and wording suggestions are now implemented. Please see some replies below starting with [Daniel]. Latest draft is at https://wai-curricula.netlify.app/curricula/content-author-modules/ <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwai-curricula.netlify.app%2Fcurricula%2Fcontent-author-modules%2 F&data=05%7C01%7CS.E.Lewthwaite%40soton.ac.uk%7Cb1e47f8e11804b704ce508da90a5b622%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C63798 1338665413606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cY6s KrJkGxp4w1PeUFiSSwRJLjwY7du3oiHSrEBrgDU%3D&reserved=0> We use to publicly archive any received comments, especially at this point. Do you have any issues with me forwarding this to the public list wai-eo-editors@w3.org <mailto:wai-eo-editors@w3.org> ? We really need to move forward now as we are in a very tight project schedule. I think these additions cover what you are asking for in the broader sense. The details on the cross-collaboration aspects could be covered in more detail, but that would potentially exclude teams that do things different than our categorization suggests (more on this below). If you have no objection, we will now proceed to the publication approval survey. --- Module 1. Clear Content Topic: visual appearance: Teaching ideas. We currently specify in the intro: "When content authors cannot specify the visual appearance, they must collaborate with other team members, such as designers and developers, to ensure accessibility of the content." Our research at Southampton bears out the need for communication and cross-role collaboration skills in accessibility. Given the importance of this, would it be possible to add a 'Teaching Idea for Topic' that suggests giving students the opportunity to collaborate (for example) with design students and student developers to solve a real world visual challenge, or alternatively setting a task that requires content author students to consider how they would communicate with colleagues in design and development about the accessibility requirements for images across a workflow, and to present their approach for class discussion? [Daniel] Added at the end of teaching idea, first bullet: Emphasize that ensuring an accessible visual appearance requires collaboration between different team members, including designers, developers, and content authors. Changed assessment, second bullet Practical — Give students a piece of content. Ask them to collaborate with other team members to ensure an accessible visual appearance. Assess how students collaborate with other team members to ensure sufficient contrast ratios, fonts that are easy to read, text spacing, text alignment, and content grouping. --- Module 2. Structure Topic Headings: Learning outcomes. Bullet 4 states: "describe the accessibility considerations when changing the default visual appearance of headings, including: * potential inaccessibility of the selected custom visual appearance * mismatch between the visual appearance of the heading and the generated markup A small point is that this learning outcome differs from other points on the list which require students to know what should be done. This learning outcome is about identifying problems. This is clear on the first sub bullet "potential inaccessibility", but not so definitive on the second "mismatch". Could this second bullet include term "inaccessibility" to ensure it is not misread? [Daniel] Changed to: * describe the accessibility considerations when changing the default visual appearance of headings, including the potential inaccessibility of: * the selected custom visual appearance * the generated markup I think this is now clear that we are expecting students to identify what can render inaccessible headings from originally accessible ones. That is, changing only the visual appearance and not updating the markup accordingly. --- Module 3. Forms Importantly, the introductory text on the Topics: Labels, Instructions and Error Messages all identify the need for different team members to collaborate where authoring tools do not produce accessible results. This could be an important teaching point, as team-working and cross-role collaboration can be modelled in the classroom prior to being experienced in the workplace. Whilst I appreciate that this could be difficult for some teachers to enact, I think it's important that Teaching Ideas for Topic includes a collaborative / team based research and discussion or presentation activity that highlights to teachers (and then their students) how building collaborative and communication competencies will ensure their students are better prepared for professional accessibility work. If we can make this more explicit that would be great. [Daniel] We previously had specific guidance for instructors on this aspect. We identified what was expected from each role in the teaching idea. But then that was flagged to be very detailed and to potentially exclude some teams that are not adjust to the usual "content author", "designer', "developer" pattern. A common ground for this could be to add the following to each of the teaching ideas for topic, first bullet: "Emphasize that providing accessible [labels] | [instructions] | [error messages] requires collaboration between different team members, including designers, developers, and content authors.. I think this gives instructors a nice pointer without getting to much into detail that could render this teaching idea useless in some situations where team roles do not follow our categorization. --- Module 5. Data Tables. In every "Teaching Ideas" section for each Topic for this module, teachers are asked to demonstrate 'assistive technology', and these are described in terms of (for example) how they 'announce the summary and description' (e.g. Topic: table summaries and descriptions, teaching ideas). However, not all assistive technologies are screen readers, or 'announce'. To add clarity, it would be helpful in each teaching ideas section if we are explicit about the type of assistive technology that is currently implied. For example, Teaching ideas for topic: Table Header Cells. Bulletpoint 1. Where we state 'demonstrate the use of assistive technologies to navigate' is there added value in suggesting types of assistive technologies? The full bulletpoint here states "emphasize how header cells are announced". In Teaching Ideas for Topic: Table Data Cells, bullet 1 states: "Some assistive technologies announce the header cell before the data cell, others do the opposite way". In both instances, does 'assistive technology' actually mean screen readers? Or could this be broader? A little more detail will help new teachers. [Daniel] Changed "assistive technologies" to "screen readers" in these two occurrences. --- Best, -- Daniel Montalvo Accessibility Education and Training Specialist W3C/WAI
Received on Wednesday, 7 September 2022 08:33:55 UTC