E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: james mathu
Date: Sun, Jan 05 2020 10:25PM
Subject: WebAIM-Forum Digest, Vol 178, Issue 4
No previous message | No next message

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 ADDRESS REMOVED = >
wrote:

> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS 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 ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS 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 ADDRESS REMOVED = )
> 3. Re: Images with captions - technical realization? (Jonathan Avila)
> 4. Re: Images with captions - technical realization?
> ( = EMAIL ADDRESS REMOVED = )
> 5. High Contrast Test (james mathu)
> 6. AccessiBe? (Colleen Gratzer)
> 7. Re: High Contrast Test ( = EMAIL ADDRESS REMOVED = )
> 8. Re: Images with captions - technical realization? (Sushil Oswal)
> 9. Re: AccessiBe? (Birkir R. Gunnarsson)
>
>
>
> ---------- Forwarded message ----------
> From: Guy Hickling < = EMAIL ADDRESS REMOVED = >
> To: webaim-forum < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
> To: "'WebAIM Discussion List'" < = EMAIL ADDRESS 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 ADDRESS REMOVED = > Im Auftrag von
> Birkir R. Gunnarsson
> Gesendet: Samstag, 4. Jänner 2020 18:55
> An: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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
>
>
>