- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Fri, 18 Dec 2020 10:57:36 +0100
- To: Shawn Henry <shawn@w3.org>
- Cc: wai-eo-editors <wai-eo-editors@w3.org>
Hi Shawn, On 17/12/2020 23:54, Shawn Henry wrote: > Hi Shadi, > > Thanks for review and comments. Would you provide more information on > some points below -- especially the last one. > > Shadi Abou-Zahra via WBS Mailer wrote: > ... >> Comments: >> [editors] "Provide a text transcript from the caption text and the >> description of visual information so that people who are Deaf-blind >> get the >> video content." -- maybe add "Some media players do this automatically"? > > I don't know of any media players that automatically combine the caption > text and description. Also, for Deaf-blind, I understand that it's > better outside of the media player. I thought AblePlayer and others do this but maybe I got this wrong. >> [editors] "Provide sign language so that Deaf people whose native >> language >> is sign get the content in their language." -- maybe add "where possible" >> to soften this a little (ie. "Provide sign language where possible" or >> such)? I know that this is not in-line with the current neutral approach >> but "provide" kind of sticks out to me. > > Yeah, I really struggle with this -- given we want everyone to provide > sign languages [plural], *and* most really cannot reasonably. > > I had appeased myself with this wording because the list is introduced > with: > [[ > This resource describes accessibility requirements in Web Content > Accessibility Guidelines (WCAG) and good practices beyond WCAG. It helps > you: > ... > * Provide sign language... > ]] > > Yet I agree that it's likely many readers will skim or skip that, and > end up with pretty much just "Provide sign language"... Agree that many people will not make this connection. Also, I don't consider sign language as "good practices beyond WCAG". > One note is that "possible" isn't quite right. I mean, it's *technically > possible* for anyone to, it's just not financially feasible for most. To me, "possible" is not limited to technical feasibility. Happy to explore other terms, I'm not the native speaker. > I'll bring to EOWG options such as: > * Provide sign language when possible, so that ... > * Provide sign language where possible, so that ... > * Provide sign language if possible, so that ... > * If feasible, provide sign language, so that ... > ... other... All fine with me. Both "possible" and "feasible" sound the same to me. >>> --------------------------------- >>> Comments on other things > ... >> [lo] "Many people who are Deaf can read text well. They get the audio >> information from transcripts or captions. Some people prefer sign >> language." -> "Many people who are Deaf get the audio information from >> transcripts or captions. Some people prefer sign language." -- the "can >> read text well" seems a little off IMO. > > humm... I was intending it to be a shortcut for: > Many people who are Deaf can read and understand written language well. > They get the audio information from transcripts or captions. Some people > who are Deaf cannot read text well, especially at the speed of most > captions. They need sign language. > > shortened to: > Many people who are Deaf can read text well. They get the audio > information from transcripts or captions. Some people prefer sign language. Yes, I recall the evolution. Yet now "Many people who are Deaf can read text well" stands out on its own in my view. It seems a little odd. > maybe: > Many people who are Deaf get the audio information from transcripts or > captions. Some people prefer the information in their native sign language. I like that direction. > /me might add a GitHub issue for this... If it resonates with other people. I don't feel strongly about this. >> [med] I find this first page extremely long an overwhelming. I wonder if >> this should become a real first page of the resource that people could >> specifically point? Something like "background" or "getting started" or >> such. > > I do not understand what you are proposing. What is the "this"? What > content on what page(s)? > > As a reminder (also in https://github.com/w3c/wai-media-guide/issues/147 ): > * In the 30 October EOWG meeting we said we wanted quick tips. > * In the 20 November EOWG meeting we looked at a Quick Tips draft page. > There was some discussion that they were too redundant with the first > page of the resource. [I think largely from SAZ] > * Here's another approach: having the quick tips as bullets in the > Summary of the first page. > * In the 4 December EOWG meeting EOWG came to a resolution to accept the > approach to include tips as a summary at the top of the first page. > > Personally I would like the quicktips on a separate page -- that is, the > new bullets currently in the draft summary. However, not strongly enough > to push if EOWG doesn't. > > /me doesn't stop herself from drafting > https://deploy-preview-149--wai-media-guide.netlify.app/media/av/quicktips/ No no no, sorry if I was unclear! I really *like* the "quick tips" on this first page. It is (1) a quick entry to the topic, (2) overview on the content, and (3) a reminder for recurring readers wanting to find particular information. This question was about "other things" and I meant everything below on this page. I think most of it could/should be moved to a separate page for those totally new to the topic. I think it would make the resource seem lighter and less overwhelming. We would also have a separate page that is easier to reference in my view (ie. "go there for the basics"). > Looking forward to EOWG discussion this week. :-) I'll try to behave... > ~Shawn Best, Shadi -- Shadi Abou-Zahra - http://www.w3.org/People/shadi/ Accessibility Strategy and Technology Specialist Web Accessibility Initiative (WAI) World Wide Web Consortium (W3C)
Received on Friday, 18 December 2020 09:57:41 UTC