- From: Marc Haunschild <haunschild@mhis.onmicrosoft.de>
- Date: Mon, 22 Mar 2021 13:54:21 +0000
- To: Louise Lister <Louise.Lister@iop.org>
- CC: WAI Interest Group discussion list <w3c-wai-ig@w3.org>
- Message-ID: <7DB08E5B-D71B-49D3-ABD3-79C85DFC4246@mhis.onmicrosoft.de>
Hi Louise, In general I would tend to prefer the visually hidden option. Why? Because in many cases for sighted people there are a lot of hints in the design. So if for whatever reason the css fails to load, there will be the hints visible for everyone. This is not a must have according to the WCAG, but I consider it best practice. The principle is called progressive enhancement. I start with the HTML, than I make the page accessible without CSS by adding necessary information, so that it works even in non graphic browsers and screenreader. Only after this I add layout with CSS. Also very basic, without columns or anything. Usually this will be quite close to what you call „mobile version“. In the next step I will add the multicolumn layout as given for desktop usage (this is called mobile first and it prevents the relatively weak mobile processors from first loading the desktop version and than rearrange everything for small screens). You have to strictly use min-size in your media queries, bust that's pretty much it to make a modern progressive, responsive, mobile first, accessible page - in a nutshell. Of course about each step are books to be written, but that’s the rough idea. So that's why I prefer visually hidden. It’s the fallback, if visual clues fail, it’s robust and will work even if everything fails except the pure HTML. Marc Am 22.03.2021 um 11:29 schrieb Louise Lister <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>>: Thanks Marc, I appreciate the ideas around hidden content. Can I ask, do you tend towards using aria labels or the visually-hidden option as a rule? With best wishes Louise From: Marc Haunschild <haunschild@mhis.onmicrosoft.de<mailto:haunschild@mhis.onmicrosoft.de>> Sent: 19 March 2021 17:36 To: Louise Lister <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>> Cc: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org> Subject: Re: Good practice options for introducing videos and tables Sorry about the caption. Of course one needs to know what video he/ she starts. So you need a caption or you could write in the hidden content "Play/ Pause the video „How to make a website accessible“" Can be also somewhere else. For example you can write the name of the videos into headings over each video, so that it reads „how to make a website accessible heading level 3 - play/ pause video“ - the complete thing has to make sense. There are many techniques to achieve this and depending on the rest of your page, you should use one or another, so that your content is presented in a consistent and predictable way. Different mixes of techniques may meet a success criterion, but still some make the page feel better, some worse, some may even confuse users, others don’t - the wcag/atag are just a minimal set of requirements. Always go for best practices, not for just enough to pass the test ;-) My answers here are not based on knowing your particular site, so my solutions may be not the best in your specific context. They are just examples to illustrate a way of thinking for everybody. To get back to the pairs of roles and Names. Other possible solutions are ordered lists (if there is a particular order for example alphabetical), unordered lists - even a simple paragraph could do the job. Of course we learn and teach all the time how to put meaning into the code with all kinds of semantics. But you might create an overkill of information. Quite a lot of screenreader users complain about too much clutter like a list for every little enumeration. So something like this might be completely ok: <p>Here are the people we work with:</p> <p>Peter (director), Naomi (Actress) and Marc (Coder)</p> This will be read like just what you want to tell. If you use a list there will be something likes this: List with three entries, Peter (director) one of three, Naomi (Actress) two of three and so on - and you could add more information while trying to make the best possible user experience, that actually might drive blind users crazy. Important thing is, that everybody gets the point! No matter whether it’s the play button or the staff. Marc Am 19.03.2021 um 17:46 schrieb Louise Lister <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>>: That’s perfect, thanks Marc. Thanks for the ideas on the video side! I was reading up about visually hiding content earlier today. I don’t think we would use dt dl in this instance, but it’s good to know that we don’t necessarily need a caption too. With kind regards Louise From: Marc Haunschild <haunschild@mhis.onmicrosoft.de<mailto:haunschild@mhis.onmicrosoft.de>> Sent: 19 March 2021 16:40 To: Louise Lister <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>> Cc: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org> Subject: Re: Good practice options for introducing videos and tables Hi Louise, For the button: use something like this inside of the button-Element in addition to the graphic: <span class="visually-hidden“>Play/ Pause video</span> Do you know how to hide content visually? In an ideal world you would use JS to show only „Play“ or „Pause“ but in the real world every screenreader user should understand a button with a text like this About your table: I’m not sure what you want. If there is jaust to columns it looks like a layout table to me and you don’t need any semantics at all Something like this is completely understandable: Director: Peter Actress: Naomi Coder: Marc If you want to add semantics I'd rather use dl with dt/dt instead… Marc Am 19.03.2021 um 15:48 schrieb Louise Lister <Louise.Lister@iop.org<mailto:Louise.Lister@iop.org>>: Hello all, I hope someone can help. Got a couple of questions about the way we introduce videos and data tables on webpages. Introducing videos We have some videos on our website that do not any introductory text. The HTML looks like this: <drupal-entity data-embed-button="video_remote_" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid=""></drupal-entity> When running NVDA over the page and tabbing through the content, it will clearly state there is a “button”, but unless you see the button in context, you may not know what it does. My thinking is that the best way to get around this is to also use content to introduce it in this way: “Watch the video below to find out how to …”, and/or change the alt text for the button graphic , if that’s possible, to “A video is playable here”. Or is there a cleverer way that I am not aware of? Introducing tables We also have some tables that are simple but don’t use a caption tag (the tag needs a tweak to make it look ‘okay’ before we use it). Instead, we often use headings instead. It sounds okay in NVDA to me, but should we be using captions as the rule? Here’s what the HTML could look like: <h2>Committee</h2> <table dir="ltr"> <tbody> <tr> <th scope="row">Role</th> <td>Person's name</td> </tr> <tr> <th scope="row">Role</th> <td>Person's name</td> </tr> </tbody> </table> Thanks, I appreciate this is probably basic stuff, just hoped for some thoughts on the above. Louise ________________________________ This email (and attachments) are confidential and intended for the addressee(s) only. If you are not the intended recipient please immediately notify the sender, permanently and securely delete any copies and do not take action with it or in reliance on it. Any views expressed are the author's and do not represent those of IOP, except where specifically stated. IOP takes reasonable precautions to protect against viruses but accepts no responsibility for loss or damage arising from virus infection. For the protection of IOP's systems and staff emails are scanned automatically.. Institute of Physics. Registered charity no. 293851 (England & Wales) and SCO40092 (Scotland) Registered Office: 37 Caledonian Road, London, N1 9BU<https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgoo.gl%2Fmaps%2FDUHbKcbzuUN2&data=04%7C01%7Clouise.lister%40iop.org%7C5b79487166af43db661d08d8eafd8894%7C8b8986af18bb4882a149fa5a3dd1f995%7C0%7C0%7C637517721921047360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r6vp215KPtfTAxhC6gixuGI4Fyx3zSpoANmpN4k6B0c%3D&reserved=0> Your privacy is important to us. For information about how IOP uses your personal data, please see our Privacy Policy<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iop.org%2Fprivacy%2Findex.html&data=04%7C01%7Clouise.lister%40iop.org%7C5b79487166af43db661d08d8eafd8894%7C8b8986af18bb4882a149fa5a3dd1f995%7C0%7C0%7C637517721921047360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hulZJ1dHruMD1epbdqT03W6aVA%2F1Tzhm%2Fl6QSPGupgg%3D&reserved=0> ________________________________ This email (and attachments) are confidential and intended for the addressee(s) only. If you are not the intended recipient please immediately notify the sender, permanently and securely delete any copies and do not take action with it or in reliance on it. Any views expressed are the author's and do not represent those of IOP, except where specifically stated. IOP takes reasonable precautions to protect against viruses but accepts no responsibility for loss or damage arising from virus infection. For the protection of IOP's systems and staff emails are scanned automatically.. Institute of Physics. Registered charity no. 293851 (England & Wales) and SCO40092 (Scotland) Registered Office: 37 Caledonian Road, London, N1 9BU<https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgoo.gl%2Fmaps%2FDUHbKcbzuUN2&data=04%7C01%7Clouise.lister%40iop.org%7C5b79487166af43db661d08d8eafd8894%7C8b8986af18bb4882a149fa5a3dd1f995%7C0%7C0%7C637517721921057351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ehtmTn1Jr2MK%2B7X%2FhaYMJlTUMeCe0YumvsgGaUtilLQ%3D&reserved=0> Your privacy is important to us. For information about how IOP uses your personal data, please see our Privacy Policy<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iop.org%2Fprivacy%2Findex.html&data=04%7C01%7Clouise.lister%40iop.org%7C5b79487166af43db661d08d8eafd8894%7C8b8986af18bb4882a149fa5a3dd1f995%7C0%7C0%7C637517721921057351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iuMpf8d8yYdvp6ZNtrNkV4UdCfMv5RlgVA5mnKPeETI%3D&reserved=0> ________________________________ This email (and attachments) are confidential and intended for the addressee(s) only. If you are not the intended recipient please immediately notify the sender, permanently and securely delete any copies and do not take action with it or in reliance on it. Any views expressed are the author's and do not represent those of IOP, except where specifically stated. IOP takes reasonable precautions to protect against viruses but accepts no responsibility for loss or damage arising from virus infection. For the protection of IOP's systems and staff emails are scanned automatically.. Institute of Physics. Registered charity no. 293851 (England & Wales) and SCO40092 (Scotland) Registered Office: 37 Caledonian Road, London, N1 9BU<https://goo.gl/maps/DUHbKcbzuUN2> Your privacy is important to us. For information about how IOP uses your personal data, please see our Privacy Policy<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iop.org%2Fprivacy%2Findex.html&data=02%7C01%7C%7C6716aa3c6fd84da5102808d5c0b234a0%7Cf9ee42e6bad04e639115f704f9ccceed%7C0%7C0%7C636626793962820374&sdata=RI6OT4MumRlklNzF5i2M9ZxS6P%2FxxLg%2FJwcnMJ%2B0480%3D&reserved=0>
Received on Monday, 22 March 2021 13:54:43 UTC