WebAIM - Web Accessibility In Mind

E-mail List Archives

WebAIM-Forum Digest, Vol 178, Issue 4

for

From: james mathu
Date: Jan 5, 2020 10:25PM

Hi Guy Hickling,

Excellent Information, thank you very much for sharing this information
with me. Right now I am working with WCAG 2.0 soon we will upgrade to 2.1

Regards,
James

On Mon, Jan 6, 2020 at 12:32 AM < <EMAIL REMOVED> >
wrote:

> Send WebAIM-Forum mailing list submissions to
> <EMAIL REMOVED>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> <EMAIL REMOVED>
>
> You can reach the person managing the list at
> <EMAIL REMOVED>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: Difference Between ADA and WCAG (Guy Hickling)
> 2. Re: Images with captions - technical realization?
> ( <EMAIL REMOVED> )
> 3. Re: Images with captions - technical realization? (Jonathan Avila)
> 4. Re: Images with captions - technical realization?
> ( <EMAIL REMOVED> )
> 5. High Contrast Test (james mathu)
> 6. AccessiBe? (Colleen Gratzer)
> 7. Re: High Contrast Test ( <EMAIL REMOVED> )
> 8. Re: Images with captions - technical realization? (Sushil Oswal)
> 9. Re: AccessiBe? (Birkir R. Gunnarsson)
>
>
>
> ---------- Forwarded message ----------
> From: Guy Hickling < <EMAIL REMOVED> >
> To: webaim-forum < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sat, 4 Jan 2020 21:30:40 +0000
> Subject: Re: [WebAIM] Difference Between ADA and WCAG
> It actually doesn't matter what the ADA says or does not say about website
> accessibility in its wording. It also isn't important what the Department
> of Justice has said, though the decisions they published in the past
> initiated today's concentration on website accessibility. The only thing
> that matters, to businesses today, is what the courts are saying about it.
> And virtually all courts have accepted that the ADA does in principle apply
> to websites.
>
> Where businesses have won court victories over a complainant it has been
> for other reasons. For instance some credit unions won cases because they
> only covered a specific area of the country, and the disabled litigant
> lived outside the area so could not be a member, so the courts decided they
> did not need to use the website. But any credit union that thinks that
> decision makes them safe is living in cloud cuckoo land, because their
> website is still non-accessible, and still wide open to challenge by some
> disabled person who *does* live in their area.
>
> Another more problematic question, that has had different decisions in
> different courts, is whether the website was sufficiently tied to a bricks
> and mortar building to be a "place of public accommodation". But any
> business making a fight over that is taking a huge risk. Far safer and
> cheaper just to make their website accessible than to risk a lawsuit over
> that. The changes required are, honestly, usually so simple.
>
> The one thing that all courts that found in favour of the disabled person
> have said, is that the website must be measured using the WCAG 2.1 Level AA
> (They used to say WCAG 2.0, but moved to 2.1 within weeks of the update
> coming out.) Never mind anything said to the contrary, if A says "I used a
> different approach", but the court says "not enough", court wins!
>
> So, James, that is what you can say to anyone asking you about it. ADA
> compliance means WCAG 2.1 compliance, because that's what the courts demand
> if it goes that far. And therefore what complainants can demand. Also
> because if their website complies with that, they are unlikely to have any
> disabled person complain in the first place since that person is unlikely
> to experience any access difficulty. But businesses need to get expert help
> from accessibility professionals, not rely on a quick test with automated
> test tools to tell them what they need to do, because those things just
> don't do the job. For instance, one of the things most mentioned in
> lawsuits is images that don't have a correct alt text. There is no tool on
> this earth that can tell developers what alt text to use!
>
> Too many businesses have gone for a cheap, quick fix, but there are far too
> many lawsuits being brought all the time to take that risk any more!
>
> Regards,
> Guy Hickling
> Accessibility Consultant
>
>
>
>
> ---------- Forwarded message ----------
> From: < <EMAIL REMOVED> >
> To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 00:04:06 +0100
> Subject: Re: [WebAIM] Images with captions - technical realization?
> Hi Birkir and interested persons on SR UX,
>
> 1. figure - figcaption concept
>
> Birkir, your example would announce "Figure 1.2 - relationship between …"
> three times while passing the figure with my SR.
> Sounds like we should avoid <figure> generally because of the verbosity, it
> causes for screen reader users. Or should screen reader devs reduce
> verbosity technically by default? (Which SR user knows enough about
> individual settings? And the general setting for reduced verbosity in Jaws
> often causes loss of information at all.)
>
> The WAI tutorial for complex images from 2015 suggests long descriptions
> placed in <figcaption> either linked or with full description text:
> https://www.w3.org/WAI/tutorials/images/complex/
> Do we have to throw away or improve this concept?
> Arrow Down interrupts the SR and continues with reading the next element.
> Is
> this the concept, we suggest to avoid/skip verbose announcements?
>
> 2. aria-details
>
> .. is only supported when focus is on it?
> https://www.w3.org/TR/wai-aria-1.1/#aria-details
>
> 3. role="presentation" on the <figure>
>
> Seems to be an interesting hack. I'm looking forward to testing the
> suggestion with SR and HTML validator.
> (<figure> doesn't make much visual noise in comparison to <table>. So, I'd
> suppose, it won't be used, unless its semantic is wished.)
>
> 4. Your "presentation on text level semantics"
>
> You call it *poor job*. Yet I still haven't found any implementation of the
> semantics You examined in any SR, I tested (ins, del, em, strong, …)
>
> Thanks,
> Wolfgang
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von
> Birkir R. Gunnarsson
> Gesendet: Samstag, 4. Jänner 2020 18:55
> An: WebAIM Discussion List < <EMAIL REMOVED> >
> Betreff: Re: [WebAIM] Images with captions - technical realization?
>
> I think the standard use case for the <figure>/<figcaption> element is a
> figure in a textbook, where the caption gives contect for the image (but is
> not alt text for the image), something like <figure> <figcaption>Figure 1.2
> - relationship between accessibility and customer satisfaction</figcaption>
> (possibly an extra line of text) <img alt="graph depicting the relationship
> showing that accessible websites score on average 20% higher in customer
> satisfaction than inaccessible sites"> </figure> (these are ficticious
> numbers) If the figure is complex the caption may also contain a table,
> ideally referenced from the image element using aria-details (though last
> time I checked I found zero support for that attribute).
>
> If the figure element is used this way the figcaption element content
> should
> not be the alt text for the image, it's about the image, it doesn't
> describe
> the image.
> Also if it is used this way the natural mapping for the figure element for
> a
> screen reader is a group or a landmark region and the screen reader will
> announce the boundries of the figure as you navigate into and out of it (I
> think this can be controled viav verbosity settings).
> It's important in this sceanrio to keep the content of the figcaption short
> and put any extra info thta is not the barebones label into a paragraph
> inside the figure, because the figcaption is used as the accessible name
> for
> the figure and repeated 2 to 3 times (if you navigate in browse mode).
>
> I think the figure element is often misused and the figcaption is
> essentially the alt text for the image, in which case you could use
> role="presentation" on the <figure> element itself and connect the image
> with the figcaption element using aria-labelledby <figure
> role="presentation"> <figcaption id="fig11">ABCD logo</figcaption> <img
> aria-labelledby="fig11"> </figure>
>
> In this scenario the problem has a lot to do with the figure element not
> being used as intended, but this ARIA workaround will eliminate the screen
> reader verbosity and expose it as an image with alt text.
>
> There are a lot of HTML element with very specific use cases and for many
> of
> them authors do not use them as intended and browsers/assistive
> technologies
> do not expose them in a way that best fits the intended purpose, instead
> mapping them to more generic roles (or sometimes ignore them).
> Using HTML to mark deleted and replaced values comes to mind, see my
> 2016 presentation on text level semantics:
> http://whoseline.a11yideas.com/01_semanticTextElements.html
>
> This is a challenge we must continue to explore and solve to promote full
> digital equality.
>
>
> On 1/3/20, <EMAIL REMOVED>
> < <EMAIL REMOVED> > wrote:
> > Hi,
> >
> > The more I read, the more I doubt about this simple issue.
> >
> > How should images with visual captions be technically realized for SR?
> >
> >
> >
> > A) <figure> with <figcaption>
> >
> > . seems to be the native semantic.
> >
> >
> >
> > But my screen reader does, what it should: It repeats the value of the
> > figcaption three times: When entering and leaving the figure-section
> > and when entering the figcaption-element.
> >
> > These redundancies disturb SR UX, although such examples are even
> > presented in the spec:
> >
> > https://html.spec.whatwg.org/multipage/grouping-content.html#the-figur
> > e-elem
> > ent
> >
> >
> >
> > 1. How to avoid these redundancies technically or with SR settings?
> >
> > 2. Should <figure> only be used, when a *long description* in the
> > <figcaption> is reasonable?
> >
> >
> >
> > B) <img> followed by <p> with captioning text
> >
> >
> >
> > 3. Could a simple <img> - <p> combination be semantically connected?
> > aria-describedby only works within focusable elements.
> >
> >
> >
> > Furthermore: Redundancies with the value of the alt-attribute
> >
> >
> >
> > 4. What if the value of the <figcaption> or <p> matches the
> > alt-attribute in the image already? If alt=NULL, the SR won't announce
> > the *existence* of an image at all, which might be useful and
> > necessary sometimes.
> >
> >
> >
> > Thanks for ideas!
> >
> >
> >
> > Wolfgang
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at
> http://webaim.org/discussion/archives
> >
>
>
>
>
> ---------- Forwarded message ----------
> From: Jonathan Avila < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 01:34:16 +0000
> Subject: Re: [WebAIM] Images with captions - technical realization?
> The HTML Accessibility API Mappings 1.0 document (
> https://www.w3.org/TR/html-aam-1.0/#figure-and-figcaption-elements)
> indicates that figcaption be used as the accessible name if there is no
> aria-labelledby or aria-label. I agree with Birkir's comment that the
> figcaption is not meant to be a replacement for any images in the figure
> -- but rather a caption for the figure.
>
> One question this does raise is whether it's a violation to have a figure
> element without an accessible name. I'd say no as the figcaption is
> optional. If there is text that acts as a caption then figcaption or
> equivalent would be needed though -- much like a table and table caption.
> Any images in the figure would need their own accessible names as well --
> unless decorative.
>
> Jonathan
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Saturday, January 4, 2020 12:55 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Images with captions - technical realization?
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> I think the standard use case for the <figure>/<figcaption> element is a
> figure in a textbook, where the caption gives contect for the image (but is
> not alt text for the image), something like <figure> <figcaption>Figure 1.2
> - relationship between accessibility and customer satisfaction</figcaption>
> (possibly an extra line of text) <img alt="graph depicting the relationship
> showing that accessible websites score on average 20% higher in customer
> satisfaction than inaccessible sites"> </figure> (these are ficticious
> numbers) If the figure is complex the caption may also contain a table,
> ideally referenced from the image element using aria-details (though last
> time I checked I found zero support for that attribute).
>
> If the figure element is used this way the figcaption element content
> should not be the alt text for the image, it's about the image, it doesn't
> describe the image.
> Also if it is used this way the natural mapping for the figure element for
> a screen reader is a group or a landmark region and the screen reader will
> announce the boundries of the figure as you navigate into and out of it (I
> think this can be controled viav verbosity settings).
> It's important in this sceanrio to keep the content of the figcaption
> short and put any extra info thta is not the barebones label into a
> paragraph inside the figure, because the figcaption is used as the
> accessible name for the figure and repeated 2 to 3 times (if you navigate
> in browse mode).
>
> I think the figure element is often misused and the figcaption is
> essentially the alt text for the image, in which case you could use
> role="presentation" on the <figure> element itself and connect the image
> with the figcaption element using aria-labelledby <figure
> role="presentation"> <figcaption id="fig11">ABCD logo</figcaption> <img
> aria-labelledby="fig11"> </figure>
>
> In this scenario the problem has a lot to do with the figure element not
> being used as intended, but this ARIA workaround will eliminate the screen
> reader verbosity and expose it as an image with alt text.
>
> There are a lot of HTML element with very specific use cases and for many
> of them authors do not use them as intended and browsers/assistive
> technologies do not expose them in a way that best fits the intended
> purpose, instead mapping them to more generic roles (or sometimes ignore
> them).
> Using HTML to mark deleted and replaced values comes to mind, see my
> 2016 presentation on text level semantics:
> http://whoseline.a11yideas.com/01_semanticTextElements.html
>
> This is a challenge we must continue to explore and solve to promote full
> digital equality.
>
>
> On 1/3/20, <EMAIL REMOVED>
> < <EMAIL REMOVED> > wrote:
> > Hi,
> >
> > The more I read, the more I doubt about this simple issue.
> >
> > How should images with visual captions be technically realized for SR?
> >
> >
> >
> > A) <figure> with <figcaption>
> >
> > . seems to be the native semantic.
> >
> >
> >
> > But my screen reader does, what it should: It repeats the value of the
> > figcaption three times: When entering and leaving the figure-section
> > and when entering the figcaption-element.
> >
> > These redundancies disturb SR UX, although such examples are even
> > presented in the spec:
> >
> > https://html.spec.whatwg.org/multipage/grouping-content.html#the-figur
> > e-elem
> > ent
> >
> >
> >
> > 1. How to avoid these redundancies technically or with SR settings?
> >
> > 2. Should <figure> only be used, when a *long description* in the
> > <figcaption> is reasonable?
> >
> >
> >
> > B) <img> followed by <p> with captioning text
> >
> >
> >
> > 3. Could a simple <img> - <p> combination be semantically connected?
> > aria-describedby only works within focusable elements.
> >
> >
> >
> > Furthermore: Redundancies with the value of the alt-attribute
> >
> >
> >
> > 4. What if the value of the <figcaption> or <p> matches the
> > alt-attribute in the image already? If alt=NULL, the SR won't announce
> > the *existence* of an image at all, which might be useful and
> > necessary sometimes.
> >
> >
> >
> > Thanks for ideas!
> >
> >
> >
> > Wolfgang
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at http://webaim.org/discussion/archives
> >
>
>
>
> ---------- Forwarded message ----------
> From: < <EMAIL REMOVED> >
> To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 18:35:54 +0100
> Subject: Re: [WebAIM] Images with captions - technical realization?
> Ok, seems we don't need <figcaption> to give <figure> an accessible name.
> Does a figure need an accessible name at all? The screen reader then just
> announces beginning and end of the segment surrounded by <figure>, which
> might be enough and reduce verbosity.
>
> What, if we *want* a caption for the figure?
> a) aria-label or aria-labelledby will read the text (referenced)
> additionally at the beginning and end. Seems OK.
> b) If we want the caption to be visual, <figcaption aria-hidden="true" >
> seems to work to reduce redundancy. Jaws 2019/Firefox 71 reads the text of
> the figcaption still at the beginning and end of the figure-segment. Seems
> OK too.
>
> But what about a simple image with a visual caption under it? Is the figure
> element useful for that anyway? Seems not.
>
> And what, if the text of the visual caption is identic with the alt-text?
> I'd suggest hiding the visual caption for SR with aria-hidden. Correct?
>
> I think, I thought to complicated before and I was confused by the WAI
> tutorial for complex images.
>
> Wolfgang
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von
> Jonathan Avila
> Gesendet: Sonntag, 5. Jänner 2020 02:34
> An: WebAIM Discussion List < <EMAIL REMOVED> >
> Betreff: Re: [WebAIM] Images with captions - technical realization?
>
> The HTML Accessibility API Mappings 1.0 document
> (https://www.w3.org/TR/html-aam-1.0/#figure-and-figcaption-elements)
> indicates that figcaption be used as the accessible name if there is no
> aria-labelledby or aria-label. I agree with Birkir's comment that the
> figcaption is not meant to be a replacement for any images in the figure
> --
> but rather a caption for the figure.
>
> One question this does raise is whether it's a violation to have a figure
> element without an accessible name. I'd say no as the figcaption is
> optional. If there is text that acts as a caption then figcaption or
> equivalent would be needed though -- much like a table and table caption.
> Any images in the figure would need their own accessible names as well --
> unless decorative.
>
> Jonathan
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Saturday, January 4, 2020 12:55 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Images with captions - technical realization?
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the
> content is safe.
>
>
> I think the standard use case for the <figure>/<figcaption> element is a
> figure in a textbook, where the caption gives contect for the image (but is
> not alt text for the image), something like <figure> <figcaption>Figure 1.2
> - relationship between accessibility and customer satisfaction</figcaption>
> (possibly an extra line of text) <img alt="graph depicting the relationship
> showing that accessible websites score on average 20% higher in customer
> satisfaction than inaccessible sites"> </figure> (these are ficticious
> numbers) If the figure is complex the caption may also contain a table,
> ideally referenced from the image element using aria-details (though last
> time I checked I found zero support for that attribute).
>
> If the figure element is used this way the figcaption element content
> should
> not be the alt text for the image, it's about the image, it doesn't
> describe
> the image.
> Also if it is used this way the natural mapping for the figure element for
> a
> screen reader is a group or a landmark region and the screen reader will
> announce the boundries of the figure as you navigate into and out of it (I
> think this can be controled viav verbosity settings).
> It's important in this sceanrio to keep the content of the figcaption short
> and put any extra info thta is not the barebones label into a paragraph
> inside the figure, because the figcaption is used as the accessible name
> for
> the figure and repeated 2 to 3 times (if you navigate in browse mode).
>
> I think the figure element is often misused and the figcaption is
> essentially the alt text for the image, in which case you could use
> role="presentation" on the <figure> element itself and connect the image
> with the figcaption element using aria-labelledby <figure
> role="presentation"> <figcaption id="fig11">ABCD logo</figcaption> <img
> aria-labelledby="fig11"> </figure>
>
> In this scenario the problem has a lot to do with the figure element not
> being used as intended, but this ARIA workaround will eliminate the screen
> reader verbosity and expose it as an image with alt text.
>
> There are a lot of HTML element with very specific use cases and for many
> of
> them authors do not use them as intended and browsers/assistive
> technologies
> do not expose them in a way that best fits the intended purpose, instead
> mapping them to more generic roles (or sometimes ignore them).
> Using HTML to mark deleted and replaced values comes to mind, see my
> 2016 presentation on text level semantics:
> http://whoseline.a11yideas.com/01_semanticTextElements.html
>
> This is a challenge we must continue to explore and solve to promote full
> digital equality.
>
>
> On 1/3/20, <EMAIL REMOVED>
> < <EMAIL REMOVED> > wrote:
> > Hi,
> >
> > The more I read, the more I doubt about this simple issue.
> >
> > How should images with visual captions be technically realized for SR?
> >
> >
> >
> > A) <figure> with <figcaption>
> >
> > . seems to be the native semantic.
> >
> >
> >
> > But my screen reader does, what it should: It repeats the value of the
> > figcaption three times: When entering and leaving the figure-section
> > and when entering the figcaption-element.
> >
> > These redundancies disturb SR UX, although such examples are even
> > presented in the spec:
> >
> > https://html.spec.whatwg.org/multipage/grouping-content.html#the-figur
> > e-elem
> > ent
> >
> >
> >
> > 1. How to avoid these redundancies technically or with SR settings?
> >
> > 2. Should <figure> only be used, when a *long description* in the
> > <figcaption> is reasonable?
> >
> >
> >
> > B) <img> followed by <p> with captioning text
> >
> >
> >
> > 3. Could a simple <img> - <p> combination be semantically connected?
> > aria-describedby only works within focusable elements.
> >
> >
> >
> > Furthermore: Redundancies with the value of the alt-attribute
> >
> >
> >
> > 4. What if the value of the <figcaption> or <p> matches the
> > alt-attribute in the image already? If alt=NULL, the SR won't announce
> > the *existence* of an image at all, which might be useful and
> > necessary sometimes.
> >
> >
> >
> > Thanks for ideas!
> >
> >
> >
> > Wolfgang
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at
> http://webaim.org/discussion/archives
> > > > at
> http://webaim.org/discussion/archives
> >
>
>
>
>
> ---------- Forwarded message ----------
> From: james mathu < <EMAIL REMOVED> >
> To: <EMAIL REMOVED>
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 23:27:15 +0530
> Subject: [WebAIM] High Contrast Test
> Hi All,
>
> Requesting you to help with this.
>
> I want to perform a high contrast test as a part of Accessibility
> testing. I am using chrome browser and i am trying to perform this test by
> using Default Windows Contrast Themes.
>
> Question1: Are those themes apply to the chrome browser & which themes we
> need to use for testing.
>
> Question 2: What is the importance of doing this High contrast test?
>
> Question 3: If those themes are not applicable on chrome browser can you
> pleas suggest me any of the good tools to perform this high contrast test.
>
> Regards,
> James
>
>
>
>
> ---------- Forwarded message ----------
> From: Colleen Gratzer < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 13:21:56 -0500
> Subject: [WebAIM] AccessiBe?
> Happy new year.
>
> I was wondering if anyone here has used AccessiBe
> (http://accessibe.com). If so, I wanted to see what you thought of it.
>
> (FWIW, I don't plan to use it. I was asked about it by a student of my
> website accessibility course.)
>
>
> Colleen Gratzer
> Certified Branding Expert + Accessibility Specialist, Gratzer Graphics LLC
> https://gratzergraphics.com
> Design Mentor and Host of the Design Domination podcast
> http://creative-boost.com
>
>
>
>
>
> ---------- Forwarded message ----------
> From: <EMAIL REMOVED>
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc: james mathu < <EMAIL REMOVED> >
> Bcc:
> Date: Sun, 05 Jan 2020 13:32:44 -0500
> Subject: Re: [WebAIM] High Contrast Test
> Hi, James.
>
> I can't speak to questions #1 or #3, but for #2, you will find a lot of
> information about the importance of checking in high-contrast mode on
> the WebAIM site:
> https://webaim.org/blog/high-contrast/
>
> Colleen Gratzer
> Certified Branding Expert + Accessibility Specialist, Gratzer Graphics
> LLC
> https://gratzergraphics.com
> Design Mentor and Host of the Design Domination podcast
> http://creative-boost.com
>
>
>
> On 05.01.2020 12:57, james mathu wrote:
> > Hi All,
> >
> > Requesting you to help with this.
> >
> > I want to perform a high contrast test as a part of Accessibility
> > testing. I am using chrome browser and i am trying to perform this test
> > by
> > using Default Windows Contrast Themes.
> >
> > Question1: Are those themes apply to the chrome browser & which themes
> > we
> > need to use for testing.
> >
> > Question 2: What is the importance of doing this High contrast test?
> >
> > Question 3: If those themes are not applicable on chrome browser can
> > you
> > pleas suggest me any of the good tools to perform this high contrast
> > test.
> >
> > Regards,
> > James
> > > > > > > > >
>
>
>
> ---------- Forwarded message ----------
> From: Sushil Oswal < <EMAIL REMOVED> >
> To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 10:45:34 -0800
> Subject: Re: [WebAIM] Images with captions - technical realization?
> If an image is accompanied by a visual caption, screen reader can read it
> and you don't need to retrofit it with an alt attribute.
>
> Sushil Oswal
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of <EMAIL REMOVED>
> Sent: Sunday, January 5, 2020 9:36 AM
> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Images with captions - technical realization?
>
> Ok, seems we don't need <figcaption> to give <figure> an accessible name.
> Does a figure need an accessible name at all? The screen reader then just
> announces beginning and end of the segment surrounded by <figure>, which
> might be enough and reduce verbosity.
>
> What, if we *want* a caption for the figure?
> a) aria-label or aria-labelledby will read the text (referenced)
> additionally at the beginning and end. Seems OK.
> b) If we want the caption to be visual, <figcaption aria-hidden="true" >
> seems to work to reduce redundancy. Jaws 2019/Firefox 71 reads the text of
> the figcaption still at the beginning and end of the figure-segment. Seems
> OK too.
>
> But what about a simple image with a visual caption under it? Is the figure
> element useful for that anyway? Seems not.
>
> And what, if the text of the visual caption is identic with the alt-text?
> I'd suggest hiding the visual caption for SR with aria-hidden. Correct?
>
> I think, I thought to complicated before and I was confused by the WAI
> tutorial for complex images.
>
> Wolfgang
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von
> Jonathan Avila
> Gesendet: Sonntag, 5. Jänner 2020 02:34
> An: WebAIM Discussion List < <EMAIL REMOVED> >
> Betreff: Re: [WebAIM] Images with captions - technical realization?
>
> The HTML Accessibility API Mappings 1.0 document
> (https://www.w3.org/TR/html-aam-1.0/#figure-and-figcaption-elements)
> indicates that figcaption be used as the accessible name if there is no
> aria-labelledby or aria-label. I agree with Birkir's comment that the
> figcaption is not meant to be a replacement for any images in the figure
> --
> but rather a caption for the figure.
>
> One question this does raise is whether it's a violation to have a figure
> element without an accessible name. I'd say no as the figcaption is
> optional. If there is text that acts as a caption then figcaption or
> equivalent would be needed though -- much like a table and table caption.
> Any images in the figure would need their own accessible names as well --
> unless decorative.
>
> Jonathan
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Saturday, January 4, 2020 12:55 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Images with captions - technical realization?
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the
> content is safe.
>
>
> I think the standard use case for the <figure>/<figcaption> element is a
> figure in a textbook, where the caption gives contect for the image (but is
> not alt text for the image), something like <figure> <figcaption>Figure 1.2
> - relationship between accessibility and customer satisfaction</figcaption>
> (possibly an extra line of text) <img alt="graph depicting the relationship
> showing that accessible websites score on average 20% higher in customer
> satisfaction than inaccessible sites"> </figure> (these are ficticious
> numbers) If the figure is complex the caption may also contain a table,
> ideally referenced from the image element using aria-details (though last
> time I checked I found zero support for that attribute).
>
> If the figure element is used this way the figcaption element content
> should
> not be the alt text for the image, it's about the image, it doesn't
> describe
> the image.
> Also if it is used this way the natural mapping for the figure element for
> a
> screen reader is a group or a landmark region and the screen reader will
> announce the boundries of the figure as you navigate into and out of it (I
> think this can be controled viav verbosity settings).
> It's important in this sceanrio to keep the content of the figcaption short
> and put any extra info thta is not the barebones label into a paragraph
> inside the figure, because the figcaption is used as the accessible name
> for
> the figure and repeated 2 to 3 times (if you navigate in browse mode).
>
> I think the figure element is often misused and the figcaption is
> essentially the alt text for the image, in which case you could use
> role="presentation" on the <figure> element itself and connect the image
> with the figcaption element using aria-labelledby <figure
> role="presentation"> <figcaption id="fig11">ABCD logo</figcaption> <img
> aria-labelledby="fig11"> </figure>
>
> In this scenario the problem has a lot to do with the figure element not
> being used as intended, but this ARIA workaround will eliminate the screen
> reader verbosity and expose it as an image with alt text.
>
> There are a lot of HTML element with very specific use cases and for many
> of
> them authors do not use them as intended and browsers/assistive
> technologies
> do not expose them in a way that best fits the intended purpose, instead
> mapping them to more generic roles (or sometimes ignore them).
> Using HTML to mark deleted and replaced values comes to mind, see my
> 2016 presentation on text level semantics:
> http://whoseline.a11yideas.com/01_semanticTextElements.html
>
> This is a challenge we must continue to explore and solve to promote full
> digital equality.
>
>
> On 1/3/20, <EMAIL REMOVED>
> < <EMAIL REMOVED> > wrote:
> > Hi,
> >
> > The more I read, the more I doubt about this simple issue.
> >
> > How should images with visual captions be technically realized for SR?
> >
> >
> >
> > A) <figure> with <figcaption>
> >
> > . seems to be the native semantic.
> >
> >
> >
> > But my screen reader does, what it should: It repeats the value of the
> > figcaption three times: When entering and leaving the figure-section
> > and when entering the figcaption-element.
> >
> > These redundancies disturb SR UX, although such examples are even
> > presented in the spec:
> >
> > https://html.spec.whatwg.org/multipage/grouping-content.html#the-figur
> > e-elem
> > ent
> >
> >
> >
> > 1. How to avoid these redundancies technically or with SR settings?
> >
> > 2. Should <figure> only be used, when a *long description* in the
> > <figcaption> is reasonable?
> >
> >
> >
> > B) <img> followed by <p> with captioning text
> >
> >
> >
> > 3. Could a simple <img> - <p> combination be semantically connected?
> > aria-describedby only works within focusable elements.
> >
> >
> >
> > Furthermore: Redundancies with the value of the alt-attribute
> >
> >
> >
> > 4. What if the value of the <figcaption> or <p> matches the
> > alt-attribute in the image already? If alt=NULL, the SR won't announce
> > the *existence* of an image at all, which might be useful and
> > necessary sometimes.
> >
> >
> >
> > Thanks for ideas!
> >
> >
> >
> > Wolfgang
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at
> http://webaim.org/discussion/archives
> > > > at
> http://webaim.org/discussion/archives
> >
> > > > >
>
>
>
>
> ---------- Forwarded message ----------
> From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
> To: <EMAIL REMOVED> , WebAIM Discussion List <
> <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Sun, 5 Jan 2020 14:01:42 -0500
> Subject: Re: [WebAIM] AccessiBe?
> I opened the webpage, pressed alt-1 to get the ADA compliant screen
> reader mode and ran Axe on the homepage.
> Any guesses for how many violations I found (if the page is accessible
> vilations should be 0)?
>
> ...
>
> 54
>
> If they have 54 violations on their own homepage, with their own
> accessibility layer turned on, well, that speaks for itself.
>
> A 30 second test shows they do not understand ARIA (instead of
> aria-expanded to indicate accordions they use the alt text "arrow
> down" on an image in the button element.
> They don't use landmarks.
> Their alt texts are often unnecessary and confusing.
> They place instructions on labels.
>
> It's roughly the equivalent of an 800 pound individual promoting magic
> weight loss formula.
> (nothing wrong with being 800 pounds, but if you are promoting a
> weight loss formula or lifestyle you probably should find a way that
> it works on your own body first)
> Here's a more general article why accessibility overlays don't work:
> https://blog.tenon.io/web-accessibility-overlays-dont-work
>
> Yes, we hope AI will develop and we can actually get more powerful
> accessibility tools, more than that, we hope browser/AT support for
> HTML will improve (e.g. accessible browser validation messages), both
> are a huge step towards accessibility, but I find a solution like this
> dangerous to both the accessibility profession and more so to the end
> users.
> (sure, I make my living as an accessibility expert, but honestly, if a
> product could take my place I would happily move on to do something
> else, I almost made it in investment banking, worked in the field for
> 7 years actually, but gave up because I couldn't access the study
> materials I needed for the CFA certification that I needed for the
> next step, if accessibility tools are good enough to replace me I
> could access the study materials and give that another try).
>
>
> On 1/5/20, Colleen Gratzer < <EMAIL REMOVED> > wrote:
> > Happy new year.
> >
> > I was wondering if anyone here has used AccessiBe
> > (http://accessibe.com). If so, I wanted to see what you thought of it.
> >
> > (FWIW, I don't plan to use it. I was asked about it by a student of my
> > website accessibility course.)
> >
> >
> > Colleen Gratzer
> > Certified Branding Expert + Accessibility Specialist, Gratzer Graphics
> LLC
> > https://gratzergraphics.com
> > Design Mentor and Host of the Design Domination podcast
> > http://creative-boost.com
> >
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
>
> > > > >