- From: Marc Haunschild <haunschild@mhis.onmicrosoft.de>
- Date: Fri, 16 Oct 2020 08:36:49 +0000
- To: w3c WAI List <w3c-wai-ig@w3.org>
- Message-ID: <880BE079-0763-4F25-B49E-B1C4034F901A@mhis.onmicrosoft.de>
Just a side note: there is no tool that checks accessibility for you. You mentioned for example WAVE, that I actually also use in my testing process. For example it finds also invisible headlines which I otherwise would have to look for in the code or by disabling all styles – both is like looking for a needle in a haystack – especially on long pages. Here WAVE helps by telling me, that h1 is missing or when heading levels are skipped. But that of course is just one thing we have to look for. For example it shows green badges for images with alternative texts but that’s not helpful, because the WCAG does not say you must have some value for the alt attribute, but that you must provide a text alternative THAT MAKE SENSE for all non textual content like images, diagrams and so on. That means for example, that it is completely okay to have a long description of the picture next to the picture. Than it is nice to have, to give it a additional alt attribute with some additional information, but it may not be necessary at all (well in most cases you’ll need it anyway…). Also decorative images MUST NOT have a value in the alt attribute. They must have an empty one though – else the screenreader would read the file name. There still is no software that can decide, whether an image is decorative or not. Even I sometimes have to ask, so author of an article. Especilly when testing in an early phase of development, when I get only examples and placeholders. Also: Calculation of accessible names is quite complicated and not every screenreader-browser.os combination has implemented it correctly. I don’t know, whether WAVE has. I give talks that last 1,5 hours just about non textual content and text alternatives for editors of web pages. So what I wanted to say: a real person has to read the provided texts on the whole page, must decide if they make sense and can be an equal alternative to images and find out, whether the images also are connected with the right texts (for example by using aria-describedby – editors know copy and paste and make mistakes by putting the right text in the wrong input fields. There is no software in the world to do this – yet. So do not rely on any automat, whether it’s WAVE, AXE, Google lighthouse or whatever. There are even developers making competitions about who can put the most accessibility failures on a webpage and still get 100 Points from Google lighthouse… For images its easy: just provide a text like “put alt text here” in the alt attribute and google will be happy (and any other software). So once again: don never rely on any software tests – they are a help for experienced testers, nothing more and nothing less. You need to get some experience yourself. Everybody can learn accessibility – but without you will never know, whether a webpage meets WCAG or not. Your employer must invest in your training or in an external expert – or in a proved accessible software solution instead of tableau. – But still than the editors must know what they do. Marc Von: Mehrnaz Ahmadi <mahmadij@gmail.com> Datum: Freitag, 16. Oktober 2020 um 01:09 An: w3c WAI List <w3c-wai-ig@w3.org> Betreff: How to check visualizations in iframes Neu gesendet von: <w3c-wai-ig@w3.org> Neu gesendet am: Freitag, 16. Oktober 2020 um 01:04 Hello, I just started a position as a BI Developer and part of my job is to check our tableau visualizations for accessibility. In the past, I used wave chrome extension, but wave doesn't seem to scan charts and visualizations since they are inside iframes. Would anyone know how I can check charts and visualizations for accessibility? Is there a tool for that? Any type of information is greatly appreciated. Thank you very much. Best, Mehrnaz
Received on Friday, 16 October 2020 08:37:07 UTC