WebAIM - Web Accessibility In Mind

E-mail List Archives

WebAIM-Forum Digest, Vol 206, Issue 8

for

From: Eilana Benish
Date: May 10, 2022 1:14PM

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 REMOVED> ‬‏>:‬

> Send WebAIM-Forum mailing list submissions to
> <EMAIL 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 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: 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 REMOVED> >
> To: WebAIM Discussion List < <EMAIL 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 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 REMOVED> >
> To: WebAIM Discussion List < <EMAIL 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 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 REMOVED> >
> To: <EMAIL 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 REMOVED>
> 101 Village Blvd
> Princeton, NJ 08540
> SMBE & Minority Owned Business
>
>
>
>
> ---------- Forwarded message ----------
> From: "Sherman, Joseph" < <EMAIL REMOVED> >
> To: Steve Green < <EMAIL REMOVED> >
> Cc: " <EMAIL REMOVED> " < <EMAIL 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 REMOVED> >
> Sent: Sunday, May 8, 2022 1:02 PM
> To: ' <EMAIL REMOVED> ' < <EMAIL 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 REMOVED> >
> Sent: 06 May 2022 17:09
> To: <EMAIL 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 REMOVED> > on behalf of
> Sherman, Joseph < <EMAIL REMOVED> >
> Sent: 06 May 2022 15:52
> To: <EMAIL 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 REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >, Steve Green <
> <EMAIL 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 REMOVED> > On Behalf Of
> Sherman, Joseph
> Sent: Tuesday, May 10, 2022 8:48 AM
> To: Steve Green < <EMAIL REMOVED> >
> Cc: <EMAIL 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 REMOVED> >
> Sent: Sunday, May 8, 2022 1:02 PM
> To: ' <EMAIL REMOVED> ' < <EMAIL 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 REMOVED> >
> Sent: 06 May 2022 17:09
> To: <EMAIL 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 REMOVED> > on behalf of
> Sherman, Joseph < <EMAIL REMOVED> >
> Sent: 06 May 2022 15:52
> To: <EMAIL 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 REMOVED> >
> To: <EMAIL 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 REMOVED> >
> To: "' <EMAIL REMOVED> '" < <EMAIL 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 REMOVED> > On Behalf Of
> Detlev Fischer
> Sent: 10 May 2022 15:29
> To: <EMAIL 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 REMOVED> *
< <EMAIL REMOVED> >