WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: WebAIM-Forum Digest, Vol 206, Issue 8

for

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

From: Eilana Benish
Date: Tue, May 10 2022 1:14PM
Subject: WebAIM-Forum Digest, Vol 206, Issue 8
No previous message | Next message →

Hi Glen

Well thank you very much for your answer

and yes I meant SC 1.3.3 sensory characteristics

the interface includes 10 buttons that right now have only label provided
with aria-label

sighted users can see right now only the shape of the buttons and screen
reader users can hear the labels - exercise one, 2, three etc…

Pressing enter or left click on the mouse on each button we'll open the
exercise

so, if I understand correctly, in order for sited users to be able to
understand the purpose of each button two each exercise, then a tooltip can
be sufficient here with mouse hover and with keyboard navigation with the
tab key. so everyone can understand the purpose of each button.

I do agree that if the buttons would appear with the text that says
exercise one, 2, 3 etc - in the first place without mouse hover and
keyboard navigation - this will provide the best user experience. but I
guess that the client wants' at least for now, to keep the interface as it
is.



‫בתאריך יום ג׳, 10 במאי 2022 ב-21:00 מאת <‪
= EMAIL ADDRESS REMOVED = ‬‏>:‬

> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/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: Regarding SC 1.3.1 (glen walker)
> 2. Re: Voiceover with Table (Priti Rohra)
> 3. jira and confluence training with unstoppable as part of
> global accessibility awareness day (Nathan Clark)
> 4. Re: PDF Form issue (Sherman, Joseph)
> 5. Re: PDF Form issue (Karen McCall)
> 6. Best screen reader suported solution for javascript-less
> table with radio inputs (Detlev Fischer)
> 7. Re: Best screen reader suported solution for javascript-less
> table with radio inputs (Steve Green)
>
>
>
> ---------- Forwarded message ----------
> From: glen walker < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Mon, 9 May 2022 12:07:19 -0600
> Subject: Re: [WebAIM] Regarding SC 1.3.1
> Hi Eilana, a couple clarifying questions first.
>
> Your subject line mentions 1.3.1 (Info and Relationships) but then your
> question at the end asked about 1.3.3 Sensory Characteristics. I don't see
> a problem with either guideline given the current information.
>
> If your page includes instructions that the user must click on the "rounded
> square button", then that would be a 1.3.3 issue. But if the instructions
> said to click on the "rounded square next button" or the "rounded square
> answer button", or included some kind of label in addition to a description
> of the shape, then it would be ok because the instructions don't rely
> "solely" on sensory characters. You also have a button name.
>
> Now, the fact that your buttons only show a picture (I'm guessing) and
> don't have a visible label, some would argue that that's not technically an
> accessibility failure because it fails for all users. If no one knows what
> the button picture means (except for maybe an assistive technology user if
> there's an aria-label), then it's an equally bad experience for everyone.
> Adding a tooltip like the gmail web interface is a great UX feature but
> isn't necessarily required for accessibility.
>
> For buttons without labels, I sometimes try to apply 3.3.2 but that
> guideline says you need labels when "user input" is required. Is clicking
> on a button considered "user input". Maybe. But the "understanding"
> section for that guideline (which is not normative) says "This Success
> Criterion does not apply to links or other controls (such as an
> expand/collapse widget, or similar interactive components) that are not
> associated with data entry."
>
> It's hard to make the call if your buttons are used for "data entry" or
> "user input".
>
> The understanding section talks about radio buttons and checkboxes needing
> labels because those elements could be part of a form and provide a way to
> supply "data entry". I have not seen a form where a button is used for
> data entry other than the final submission of the form itself. If you have
> several submit buttons, such as "submit form to person X" and "submit form
> to person Y", then mayyyyybe that's considered part of the data entry????
>
> At this point, you have to go beyond conformance and decide what's best for
> all users whether your situation technically fails WCAG or not.
>
>
>
> On Mon, May 9, 2022 at 9:27 AM Eilana Benish < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hello everybody
> >
> > I am testing a system Which provides Lessons And exercises For students.
> > This system Should be accessible To meet WCAG 2.0 Level A and AA
> >
> > In every topic There is 10 buttons in the shape of Rounded square Icons
> for
> > each exercise, That can be navigated with the keyboard And they have
> labels
> > for screen readers To indicate The number of the exercise.
> >
> > Keyboard navigation is good with the tab and shift+tab keys and the arrow
> > keys
> >
> > The buttons are clearly labeled for the screen readers
> >
> > focus visible on the buttons when navigating is good
> >
> > but there is no indication with text such as tooltip or title.
> >
> > The question is, is it enough two add a visible tooltip or a title- so
> the
> > text for the button can be seen with mouse hover and when a button
> receives
> > keyboard focus?
> >
> > I see this implementation for example in the Gmail app for the web, when
> > the text for the settings button for example can be seen with mouse hover
> > and when that button receives keyboard focus…
> >
> > The company that I am testing this application tells me that if not they
> > should go back to the design stage two change the design of that part…
> >
> > So is this implementation like in the Gmail app meets success criteria
> > 1.3.3 Sensory Characteristics?
> >
> > https://www.w3.org/WAI/WCAG21/Understanding/sensory-characteristics.html
> >
> > Thanks in advance
> >
> > Eilana Benish
> > > > > > > > > >
>
>
>
>
> ---------- Forwarded message ----------
> From: Priti Rohra < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Tue, 10 May 2022 16:18:45 +0530
> Subject: Re: [WebAIM] Voiceover with Table
> Hi Sumit,
>
> End of row is announced as you are interacting with the row. When you
> are interacting with the row the mentioned behavior is expected and
> not a bug. You should use VO + Left, Right Arrow keys to move between
> the cells in a row and VO + Up, Down Arrow keys to move between the
> cells on different rows.
>
> For example, we screen reader users will interact with the row if we
> need to read the spelling of a word within a cell.
>
> Best Regards
> Priti Rohra
>
>
> On 5/9/22, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
> > hai all,
> >
> > I am new to Voiceover screen reader in Mac OS. I was testing a table
> > with Voiceover in Safari browser. I just pressed VO key + shift + down
> > arrow to enter into the table. Then I was able to navigate through
> > each cells in the first row using VO key + right / left arrow keys.
> > But, when I tried to go to next row using VO key + down arrow ,
> > Voiceover is announcing as "end of row", not able to go to below rows.
> > But, when I turne off the quick nav , am able to navigate to below
> > rows. Is it an expected behavior of Voiceover screen reader or an
> > issue?
> > FYI : The table is within a dialog.
> >
> > Anyone has any idea
> >
> > Regards,
> > Sumit
> > > > > > > > > >
>
>
>
>
> ---------- Forwarded message ----------
> From: Nathan Clark < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Cc:
> Bcc:
> Date: Tue, 10 May 2022 08:18:31 -0400
> Subject: [WebAIM] jira and confluence training with unstoppable as part of
> global accessibility awareness day
> Dear list,
>
> My company Addteq is putting on two training sessions as part of
> global accessibility awareness day. My company is a platinum level
> partner solutions to Atlassian government solutions. Here at Addteq we
> have created the only section 508 accessible tool for blind users to
> use with Atlassian's tools such as Jira and Confluence which is called
> Unstoppable. On may 19 we are having two sessions of training, one for
> Jira and one for Confluence. Me and one of my co-workers will teach
> you everything you need to know about unstoppable for Jira and
> Confluence. I will be sending out the registration link as soon as I
> have it but I just wanted to let people know of this training
> opportunity on May 19. Thanks.
>
> Sincerely,
> Nathan Clark
>
>
>
> --
> Nathan Clark
> QA Automation Analyst Tech team
> Accessibility assistant
> CPACC
> cell: 410-446-7259
> email: = EMAIL ADDRESS REMOVED =
> 101 Village Blvd
> Princeton, NJ 08540
> SMBE & Minority Owned Business
>
>
>
>
> ---------- Forwarded message ----------
> From: "Sherman, Joseph" < = EMAIL ADDRESS REMOVED = >
> To: Steve Green < = EMAIL ADDRESS REMOVED = >
> Cc: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
> Bcc:
> Date: Tue, 10 May 2022 12:48:06 +0000
> Subject: Re: [WebAIM] PDF Form issue
> Hi Steve.
>
> Thanks much! That worked perfectly. Not sure how those empty characters
> got there, I did not create the original PDF.
>
> Joseph
>
> -----Original Message-----
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> Sent: Sunday, May 8, 2022 1:02 PM
> To: ' = EMAIL ADDRESS REMOVED = ' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] PDF Form issue
>
> I get the same issue as you - JAWS and NVDA do not announce the names of
> some form controls.
>
> The cause surprised me, but the fix is easy. If you go into the Properties
> of any form control that JAWS and NVDA do not announce, you will see there
> is what looks like a space at the end of the Name field. It's not a space
> because Acrobat doesn't let you put one at the end of the Name. It's some
> other non-printing character.
>
> All you need to do is delete the "space" character, close the Properties
> dialog and repeat for all the other form controls.
>
> Steve
>
>
> -----Original Message-----
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> Sent: 06 May 2022 17:09
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: PDF Form issue
>
> I would be happy to take a look if you want to email the document to me.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of
> Sherman, Joseph < = EMAIL ADDRESS REMOVED = >
> Sent: 06 May 2022 15:52
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] PDF Form issue
>
> Hi all,
>
> I am having a problem with a PDF Form I am working on. It has been tagged
> and all tooltips have been added. The tag structure of each form field is
> the same. However, JAWS and NVDA read some of the form fields perfectly,
> and other fields JAWS and NVDA do not recognize as fields or read the
> tooltips. I am usually pretty decent with PDF forms, and I have never had
> this before. The PDF passes the Adobe check and the relevant CommonLook
> checks.
>
> Anyone have any idea what might be happening? Thanks,
>
> Joseph
>
> > > at http://webaim.org/discussion/archives
> >
>
>
>
>
> ---------- Forwarded message ----------
> From: Karen McCall < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >, Steve Green <
> = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Tue, 10 May 2022 13:11:04 +0000
> Subject: Re: [WebAIM] PDF Form issue
> It sounds like the person creating the form copied the text into the form
> control name which means that the "line end" or "paragraph end" mark was
> included.
>
> Cheers, Karen
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Sherman, Joseph
> Sent: Tuesday, May 10, 2022 8:48 AM
> To: Steve Green < = EMAIL ADDRESS REMOVED = >
> Cc: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] PDF Form issue
>
> Hi Steve.
>
> Thanks much! That worked perfectly. Not sure how those empty characters
> got there, I did not create the original PDF.
>
> Joseph
>
> -----Original Message-----
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> Sent: Sunday, May 8, 2022 1:02 PM
> To: ' = EMAIL ADDRESS REMOVED = ' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] PDF Form issue
>
> I get the same issue as you - JAWS and NVDA do not announce the names of
> some form controls.
>
> The cause surprised me, but the fix is easy. If you go into the Properties
> of any form control that JAWS and NVDA do not announce, you will see there
> is what looks like a space at the end of the Name field. It's not a space
> because Acrobat doesn't let you put one at the end of the Name. It's some
> other non-printing character.
>
> All you need to do is delete the "space" character, close the Properties
> dialog and repeat for all the other form controls.
>
> Steve
>
>
> -----Original Message-----
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> Sent: 06 May 2022 17:09
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: PDF Form issue
>
> I would be happy to take a look if you want to email the document to me.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of
> Sherman, Joseph < = EMAIL ADDRESS REMOVED = >
> Sent: 06 May 2022 15:52
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] PDF Form issue
>
> Hi all,
>
> I am having a problem with a PDF Form I am working on. It has been tagged
> and all tooltips have been added. The tag structure of each form field is
> the same. However, JAWS and NVDA read some of the form fields perfectly,
> and other fields JAWS and NVDA do not recognize as fields or read the
> tooltips. I am usually pretty decent with PDF forms, and I have never had
> this before. The PDF passes the Adobe check and the relevant CommonLook
> checks.
>
> Anyone have any idea what might be happening? Thanks,
>
> Joseph
>
> > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&amp;data%7C01%7C%7Cd367b37b6d30422dacde08da32835b16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637877837021255147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata³tPl1LvT9JNvWIXO6qcj302S60BbOahXpTWfH7dCC4%3D&amp;reserved=0
> List archives at
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7C%7Cd367b37b6d30422dacde08da32835b16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637877837021255147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=QG9pBr76SC%2Fm5%2Bksn9%2BFd8UagVhgYEZp4pSimkymCVs%3D&amp;reserved=0
> >
> > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&amp;data%7C01%7C%7Cd367b37b6d30422dacde08da32835b16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637877837021255147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata³tPl1LvT9JNvWIXO6qcj302S60BbOahXpTWfH7dCC4%3D&amp;reserved=0
> List archives at
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7C%7Cd367b37b6d30422dacde08da32835b16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637877837021255147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=QG9pBr76SC%2Fm5%2Bksn9%2BFd8UagVhgYEZp4pSimkymCVs%3D&amp;reserved=0
> >
>
>
>
> ---------- Forwarded message ----------
> From: Detlev Fischer < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Cc:
> Bcc:
> Date: Tue, 10 May 2022 16:28:42 +0200
> Subject: [WebAIM] Best screen reader suported solution for javascript-less
> table with radio inputs
> Hi,
> I am looking for the best solution for tabular entries (of travel
> bookings) to be selected in a radio input pattern (i.e. only one of many
> table rows gets selected). Note that the site is not allowed to use
> JavaScript.
>
> The radio inputs are in the first column, and labelled by the entries
> (travel id, name, destination, date of travel, etc) of the same row,
> which ensures that any click on label text in that row selects the
> respective input at the beginning of the row. You cannot know which of
> the parts of the travel data in that row may be relevant for users'
> selection, therefore *all* label elements in the row are exposed, using
> multiple native label elements for the same input.
>
> It would be ideal to have a solution that allows table navigation also -
> i.e. screen reader users can decide to run just through column "Date" to
> find an entry with a particular date. This works alright when leaving
> forms mode in NVDA/Chrome: cell content is read, and column headers are
> also read. In JAWS/Chrome however, it seems that putting table cell
> content inside a label element prevents it from being exposed in table
> navigation mode: I can navigate the table with Ctrl + Alt + arrow keys,
> but I only get the column headers, the cell content is announced as empty.
>
> Since without JS there seems to be no way of making the labels in the
> table row clickable unless they are label elements for the respective
> input linked with the for attribute, solutions using aria-labelledby on
> th einputs referring to multiple ids seems out of the question - because
> then, users would be forced to click the tiny radio input to select it,
> not its labels.
>
> Is there something clever - and not too much of a hack - that would lead
> to a javascript-less table that supports selection of properly labelled
> radio inputs in forms mode, and still allows free SR navigation of the
> table in JAWS Browse mode / Virtual PC cursor mode?
>
> Any ideas?
>
> Many thanks in advance for any ideas!
> Detlev
>
> --
> Detlev Fischer
> DIAS GmbH
> (Testkreis is now part of DIAS GmbH)
>
> Mobil +49 (0)157 57 57 57 45
>
> http://www.dias.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> To: "' = EMAIL ADDRESS REMOVED = '" < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Tue, 10 May 2022 17:05:52 +0000
> Subject: Re: [WebAIM] Best screen reader suported solution for
> javascript-less table with radio inputs
> I get the same as you. I have no idea why the cell contents don't get read
> out, but there is an easy fix. You just need to put the text in a <span>
> element inside the <label> element.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Detlev Fischer
> Sent: 10 May 2022 15:29
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Best screen reader suported solution for javascript-less
> table with radio inputs
>
> Hi,
> I am looking for the best solution for tabular entries (of travel
> bookings) to be selected in a radio input pattern (i.e. only one of many
> table rows gets selected). Note that the site is not allowed to use
> JavaScript.
>
> The radio inputs are in the first column, and labelled by the entries
> (travel id, name, destination, date of travel, etc) of the same row, which
> ensures that any click on label text in that row selects the respective
> input at the beginning of the row. You cannot know which of the parts of
> the travel data in that row may be relevant for users'
> selection, therefore *all* label elements in the row are exposed, using
> multiple native label elements for the same input.
>
> It would be ideal to have a solution that allows table navigation also -
> i.e. screen reader users can decide to run just through column "Date" to
> find an entry with a particular date. This works alright when leaving forms
> mode in NVDA/Chrome: cell content is read, and column headers are also
> read. In JAWS/Chrome however, it seems that putting table cell content
> inside a label element prevents it from being exposed in table navigation
> mode: I can navigate the table with Ctrl + Alt + arrow keys, but I only get
> the column headers, the cell content is announced as empty.
>
> Since without JS there seems to be no way of making the labels in the
> table row clickable unless they are label elements for the respective input
> linked with the for attribute, solutions using aria-labelledby on th
> einputs referring to multiple ids seems out of the question - because then,
> users would be forced to click the tiny radio input to select it, not its
> labels.
>
> Is there something clever - and not too much of a hack - that would lead
> to a javascript-less table that supports selection of properly labelled
> radio inputs in forms mode, and still allows free SR navigation of the
> table in JAWS Browse mode / Virtual PC cursor mode?
>
> Any ideas?
>
> Many thanks in advance for any ideas!
> Detlev
>
> --
> Detlev Fischer
> DIAS GmbH
> (Testkreis is now part of DIAS GmbH)
>
> Mobil +49 (0)157 57 57 57 45
>
> http://www.dias.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> > > at http://webaim.org/discussion/archives
> > > > > >


--


*ובכבוד רב,*

*אילנה בניש מורשה נגישות שירות 2200*

*ייעוץ, ליווי והערכת נגישות ושמישות אינטרנט וטכנולוגיות מידע*
<https://adn-accesstime.com>
*טלפון ישיר 📱 +972-50-7100367 | דוא"ל 📧 ** = EMAIL ADDRESS REMOVED = *
< = EMAIL ADDRESS REMOVED = >

From: Kristen Smith
Date: Thu, May 26 2022 12:02PM
Subject: Re: WebAIM-Forum Digest, Vol 206, Issue 23
← Previous message | Next message →

Thanks! Can you send me your total billed time from yesterday and today?

Thanks!
Kristen Smith-O'Connor
CPACC, Trusted Tester v5

= EMAIL ADDRESS REMOVED =
Phone: 703-356-8035, ext. 139

****Email confidentiality notice****The information transmitted by this email is intended only for the person or entity to which it is addressed. This email may contain proprietary, business-confidential, and/or privileged material. If you are not the intended recipient of this message, be aware that any use, review, retransmission, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this in error, please contact the sender and delete the material from all computers.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, May 26, 2022 2:00 PM
To: = EMAIL ADDRESS REMOVED =
Subject: WebAIM-Forum Digest, Vol 206, Issue 23

Send WebAIM-Forum mailing list submissions to
= EMAIL ADDRESS REMOVED =

To subscribe or unsubscribe via the World Wide Web, visit
https://url.emailprotection.link/?b15YKRrmJkqF_Ro_MvdjZCSw88EaAL7HL_t3W947XxLxo0BzhiNlc3Xt2j8cT9rOEkM5W5ukxf_IOrNVKRD07KbVYF8xDaGBJ2eZu208jy7zYne455ufPLbbC_xtzWDRP
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..."

From: Kristen Smith
Date: Thu, May 26 2022 12:20PM
Subject: Re: Recall: WebAIM-Forum Digest, Vol 206, Issue 23
← Previous message | No next message

Kristen Smith would like to recall the message, "WebAIM-Forum Digest, Vol 206, Issue 23".