Improve accessibility for the visually impaired

[neosonic2]

I am a completely blind individual using the VoiceOver screen reading program on macOS to navigate around the Internet, including working inside Freescout.

While the Web app is pretty accessible out of the box, there are many areas of the interface that could use some improvement in terms of how they are read by and made interactible with screen readers.

What plans do the Freescout team have for improving the accessibility of this app for those who use screen readers and other assistive technologies?

I am a Web developer experienced in PHP and the Laravel framework (versions 7 and 8 though, not version 5) as well as Web accessibility standards like ARIA. I would be happy to help contribute to this effort, especially since I already know, based on my usage of Freescout as a blind individual, what elements should be made more accessible and how their accessibility can be improved, without sacrificing their functionality or visual appearance. If you would like me to assist in this endeavor please let me know how I can get started.

Thank you!

[freescout-helpdesk]

You can create a simple custom module (Improved Accessibility, for example) and we will add it to https://github.com/freescout-helpdesk/freescout/wiki/Community-Modules. When activated the module will adjust the CSS of the FreeScout. You can create a GitHub repo for the module, so that other can also contribute.

Here is the info on developing modules: https://github.com/freescout-helpdesk/freescout/wiki/Modules-Development

[neosonic2]

Thanks for your reply. However, the accessibility changes/improvements that are needed would require modifying the HTML of the core Freescout application, i.e. to add or improve ARIA roles and other attributes. Could this be done by creating a custom module as you suggest? I'm not going to be changing anything visually so I probably wouldn't be editing any CSS; I would mostly just be making HTML changes.

[freescout-helpdesk]

Yes. Just use Actions and Filters.

[neosonic2]

After some further investigation, it looks like a lot of the accessibility changes I need to make can be done to the HTML within the resources/views folder. For example, there are unlabeled buttons that change the conversation type from e-mail to phone and are located in resources/views/conversations/create.blade.php that could be edited. Once these changes are made, can I create a pull request here to merge my accessibility enhancements into the core project?

[freescout-helpdesk]

Yes.

[fulldecent]

@neosonic2 Could you please provide one example of a thing we can change. Let's start with that and then make a process to fix more

[neosonic2]

Certainly. One thing that, as of right now, is completely inaccessible in the Freescout user interface are the buttons for sending a reply, adding a note, and performing related actions while viewing a specific conversation. The buttons nearby, i.e. for setting the status of a conversation and assigning it to a different user, and even the dropdown menu that allows a conversation to be forwarded and etc., are accessible, but the aforementioned actions are not.

Something else that could be made more accessible are certain buttons throughout the application that do not have ARIA labels on them that identifies them to screen reader users even when the button is just an icon (and thus contains no text). Examples of these are found in the HTML editor used when writing conversations, or in the buttons to switch a new conversation from an e-mail to a note, or even in the assignment, status, and other buttons mentioned previously when viewing a specific conversation.

On Jun 22, 2021, at 12:39 PM, William Entriken @.***> wrote:

@neosonic2 https://github.com/neosonic2 Could you please provide one example of a thing we can change. Let's start with that and then make a process to fix more

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-866149446, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDDRGC24Q6WN6PM3XYLTUC4DTANCNFSM42WBJFHQ.

[fulldecent]

@neosonic2 Awesome, thank you.

And are you able to run a copy of FreeScout using a specific git branch in order to evaluate if a PR fixes the problem?

[neosonic2]

Yes. I have a local development environment on my Mac that can be used to run specific branches of software as required.

I also have experience in developing for accessibility, in making Websites and Web applications accessible, etc. As a visually impaired individual, accessibility was something I learned about from the start when learning to develop for the Web, so I am willing to assist in getting these issues fixed, and in testing potential fixes, wherever necessary. I am also willing to provide any additional information as required, and test using multiple screen reading programs on multiple operating systems (I currently have macOS and Windows available).

On Jun 22, 2021, at 5:48 PM, William Entriken @.***> wrote:

@neosonic2 https://github.com/neosonic2 Awesome, thank you.

And are you able to run a copy of FreeScout using a specific git branch in order to evaluate if a PR fixes the problem?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-866359668, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDBLG4B2LRTJINU6IATTUEALNANCNFSM42WBJFHQ.

[fulldecent]

Here is a shot to fix just the action buttons.

https://github.com/freescout-helpdesk/freescout/pull/1285

The drop down is not as straightforward.

Does this fix the reply/note/delete buttons for you?

[neosonic2]

Thanks for putting this together. I haven’t had a chance to look at it yet but will do so later today and let you know if the buttons are fixed. Just wanted to acknowledge I saw your reply. Also off hand without looking at the code for the dropdown, adding the “aria-label” attribute to the dropdown element (the clickable element that opens the menu) should be enough to make those accessible, as the only issue with them is that they are simply missing labels.

On Jun 24, 2021, at 12:29 AM, William Entriken @.***> wrote:

Here is a shot to fix just the action buttons.

1285 https://github.com/freescout-helpdesk/freescout/pull/1285

The drop down is not as straightforward.

Does this fix the reply/note/delete buttons for you?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-867325281, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDD6ESKD5R4IPGCADN3TUKYA3ANCNFSM42WBJFHQ.

[fulldecent]

Currently they do have a title, which I think DOES get picked up. So I just added the role. But only testing can be sure...

[neosonic2]

Just had a second to grab the pull request and test locally. Adding role=“button” to the three conversation action buttons did the trick - they are now completely accessible. It may be helpful to wrap them inside a “Conversation actions” region (i.e. an invisible div with a role of region and an aria-label attribute of “Conversation actions”) so that when navigating by landmarked regions on the page, the actions can easily be found. However, this isn’t as high priority really unless we also want to wrap other key parts of their page in their own landmarks for easier discovery by screen readers.

On Jun 24, 2021, at 2:16 PM, William Entriken @.***> wrote:

Currently they do have a title, which I think DOES get picked up. So I just added the role. But only testing can be sure...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-867854483, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDDD7FBNXUYGZDUSE43TUNZBVANCNFSM42WBJFHQ.

[fulldecent]

Nice!

Okay, I learned one part here. If you can help identify all other roles that need to be updated just like me know and I can help hunt them down. Let's do that as one pull request. Maybe that's enough to address this issue and should be the biggest help.

And then as you said, let's do regions separately. Since this may require new text, and localizations, and input from design. We can make new issues for other accessibility issues if needed.

[neosonic2]

Sure. I know you were originally going to work on the dropdown menus near the conversation action buttons, but you said those might be more difficult. Looking at the code, it seems these dropdown already have the button role on their parent span element (that is clicked to open the menu), but are missing an aria-label attribute. The containing element of the span seems to have a title attribute but this doesn’t work with accessibility as usually aria-labels are preferred.

On Jun 25, 2021, at 10:43 AM, William Entriken @.***> wrote:

Nice!

Okay, I learned one part here. If you can help identify all other roles that need to be updated just like me know and I can help hunt them down. Let's do that as one pull request. Maybe that's enough to address this issue and should be the biggest help.

And then as you said, let's do regions separately. Since this may require new text, and localizations, and input from design. We can make new issues for other accessibility issues if needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868550249, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDAZNUK5IAFKSJVNCJLTUSIZJANCNFSM42WBJFHQ.

[fulldecent]

Cool. Added more button roles at role="button". I think this should fix it.

In general, I have been using aria-label only when the reader text differs from the literal text in HTML (e.g. for icons and other visual explanation of intent).

[neosonic2]

That’s a good strategy, however some screen readers do not report e.g. things like title labels on elements and will only report aria-labels. For example, I am using VoiceOver on macOS. All of the dropdown next to the conversation action buttons, i.e. the one for assigning the conversation to someone else, are unlabeled. Adding aria-label attributes to these elements would provide context to screen reading programs that may already be available in other forms to sighted users.

On Jun 25, 2021, at 9:27 PM, William Entriken @.***> wrote:

Cool. Added more button roles at role="button". I think this should fix it.

In general, I have been using aria-label only when the reader text differs from the literal text in HTML (e.g. for icons and other visual explanation of intent).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868903751, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDHRWK5EY5KCVQ5AIMDTUUUHFANCNFSM42WBJFHQ.

[fulldecent]

Got it, cool. OK, so I have added aria-label everywhere that we have a role="button" and a title but do not have the essential text inside that element.

[neosonic2]

I just pulled down the latest changes to the pull request but when I load the app in my browser it doesn’t look like anything has changed…Can you give me an example of a button you specifically modified so I can see if for some reason I just still don’t have the latest changes or something? I suspect something just may not have synced on my end perhaps.

On Jun 25, 2021, at 9:51 PM, William Entriken @.***> wrote:

Got it, cool. OK, so I have added aria-label everywhere that we have a role="button" and a title but do not have the essential text inside that element.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868925558, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDF7XIHMWAOSFP34JE3TUUXBDANCNFSM42WBJFHQ.

[fulldecent]

Yes, one example is the Reply button. As of yesterday, my branch only added a role="button" but today it also includes the aria-label.

[neosonic2]

The Reply button is part of the three conversation action buttons right? That was one of the buttons that was initially completely inaccessible when we started all of this but then after your first batch of changes yesterday I noticed it was working for me. I think at first all you did was just add a button role but honestly I don’t remember and I’ve already pulled down the latest code so I can’t go back. Did you add aria-labels to the other controls outside of the action buttons?

On Jun 25, 2021, at 10:06 PM, William Entriken @.***> wrote:

Yes, one example is the Reply button. As of yesterday, my branch only added a role="button" but today it also includes the aria-label.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868927739, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDFRNHU6VB3ECNZSMODTUUY2LANCNFSM42WBJFHQ.

[fulldecent]

Yes. Let me give you a full accounting of the changes here:

• Reply — added aria-label
• Note — added aria-label
• Delete — added aria-label
• Delete forever — added aria-label
• Run workflow — added aria-label
• Follow
• Unfollow
• Print
• Merge
• Delete
• Delete forever
• Account (application page) — added aria-label
• Search (application page) — added aria-label

[neosonic2]

I can see the Reply, Add Note, and Delete buttons but I could yesterday as well after you Madde initial changes. Those buttons were not visible to VoiceOver at all, and no they show up as regular buttons on the page. The dropdown menus next to those though (i.e. for assigning the conversation or setting its status), while they appear, are not actually labeled so I always have to click on one to open its options in order to see what it does (or just remember which button does what based on where they are located).

On Jun 25, 2021, at 10:11 PM, William Entriken @.***> wrote:

Yes. Let me give you a full accounting of the changes here:

Reply Note Delete Delete forever Run workflow — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868928531, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDGK3JIPSOZSFZ4I5DLTUUZNVANCNFSM42WBJFHQ.

[fulldecent]

I took a stab at labeling the dropdowns.

[neosonic2]

Oh OK awesome, now I see the “Status” dropdown is labeled now. If that’s the only one you did (since the other ones don’t have labels) then I think what you did works perfectly so you can duplicate it on the others if you’d like. I’d help contribute here but I don’t know how to add code to the pull request you are working on (I am not extremely familiar with Git and only know the basics).

On Jun 25, 2021, at 10:49 PM, William Entriken @.***> wrote:

I took a stab at labeling the dropdowns.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868933250, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDEGKAEVXTHTGMGNWRTTUU54BANCNFSM42WBJFHQ.

[neosonic2]

On a related note while we are talking about labeling things, I am looking at an individual conversation and I see there is an unlabeled link between the last folder in the list of folders and the “New Conversation” link. Even though it’s a link, I am guessing it should probably be re-classified as a menu button as it appears to drop down a menu when clicked, that has options like Edit Mailbox, Connection Settings, Permissions, etc.

Also I just saw your labeling of the “Account” and “Search” menus in the application’s layout blade, they are perfect now, thank you.

On Jun 25, 2021, at 10:49 PM, William Entriken @.***> wrote:

I took a stab at labeling the dropdowns.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868933250, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDEGKAEVXTHTGMGNWRTTUU54BANCNFSM42WBJFHQ.

[fulldecent]

Cool. Thank you for showing me how to set these up.

Hopefully somebody else can help with menus and reclassification.

At this moment PR https://github.com/freescout-helpdesk/freescout/pull/1285 might be good to merge as an incremental improvement.

[neosonic2]

Can you try to add the button role to the unlabeled link I’m talking about, and maybe an aria-label as well so that the link/button becomes labeled? Honestly that’s all that needs to be done to make that item accessible. If not though that’s OK, you’ve already done a lot thus far as you said and this PR looks great and will provide some much-needed accessibility enhancements to the application.

On Jun 26, 2021, at 2:09 AM, William Entriken @.***> wrote:

Cool. Thank you for showing me how to set these up.

Hopefully somebody else can help with menus and reclassification.

At this moment PR #1285 https://github.com/freescout-helpdesk/freescout/pull/1285 might be good to merge as an incremental improvement.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868954611, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDHEXNMZC7X4YRHVA33TUVVJVANCNFSM42WBJFHQ.

[fulldecent]

Cool. I just added those button roles and found an extra aria-label.

I do want to get the buttons in. And I know that if I mess with drop downs that I might break something. Right now I'm looking to make a few commits that are easy to review and uncontroversial to merge since I'm new here. 😄

[neosonic2]

I’ve made a few more accessibility changes to the same area you’ve been working in, such as adding proper labels to the assignee and more actions menus, and adding the status text and the assignee name to the existing labels you already had for those two dropdown menus. Is there any way that I can add this code to your existing pull request so you can see what I’ve done? I have already tested my c changes in a browser and they seem to work well alongside what you had already done.

On Jun 26, 2021, at 2:19 AM, William Entriken @.***> wrote:

Cool. I just added those button roles and found an extra aria-label.

I do want to get the buttons in. And I know that if I mess with drop downs that I might break something. Right now I'm looking to make a few commits that are easy to review and uncontroversial to merge since I'm new here. 😄

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-868955567, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDFD7GYS6XRRB3CCKZLTUVWPTANCNFSM42WBJFHQ.

[fulldecent]

Please run git diff and paste the result here

[neosonic2]

diff --git a/resources/views/conversations/view.blade.php b/resources/views/conversations/view.blade.php
index 4ea839c5..00ba1853 100644
--- a/resources/views/conversations/view.blade.php
+++ b/resources/views/conversations/view.blade.php
@@ -38,7 +38,7 @@
                     @action('conversation.action_buttons', $conversation, $mailbox){{--<span class="conv-run-workflow conv-action glyphicon glyphicon-flash" data-toggle="tooltip" data-placement="bottom"  title="{{ __("Run Workflow") }}" onclick="alert('todo: implement workflows')" data-toggle="tooltip" aria-label="{{ __("Run Workflow") }}" role="button"></span>--}}

                     <div class="dropdown conv-action" data-toggle="tooltip" title="{{ __("More Actions") }}">
-                        <span class="conv-action glyphicon glyphicon-option-horizontal dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false"></span>
+                        <span class="conv-action glyphicon glyphicon-option-horizontal dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false" aria-label="{{ __("More Actions") }}"></span>
                         <ul class="dropdown-menu dropdown-with-icons">
                             @action('conversation.prepend_action_buttons', $conversation, $mailbox)
                             <li>
@@ -71,8 +71,8 @@
                     @if ($conversation->state != App\Conversation::STATE_DELETED)
                         <li>
                             <div class="btn-group" id="conv-assignee" data-toggle="tooltip" title="{{ __("Assignee") }}: {{ $conversation->getAssigneeName(true) }}">
-                                <button type="button" class="btn btn-default conv-info-icon" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-title="{{ __("Assignee") }}"><i class="glyphicon glyphicon-user"></i></button>
-                                <button type="button" class="btn btn-default dropdown-toggle conv-info-val" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-title="{{ __("Assignee") }}">
+                                <button type="button" class="btn btn-default conv-info-icon" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-title="{{ __("Assignee") }}" aria-hidden="true"><i class="glyphicon glyphicon-user"></i></button>
+                                <button type="button" class="btn btn-default dropdown-toggle conv-info-val" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-title="{{ __("Assignee") }}" aria-label="{{ __("Assignee") }}: {{ $conversation->getAssigneeName(true) }}">
                                     <span>{{ $conversation->getAssigneeName(true) }}</span>
                                     <span class="caret"></span>
                                 </button>
@@ -91,7 +91,7 @@
                     <li>
                         <div class="btn-group" id="conv-status" data-toggle="tooltip" title="{{ __("Status") }}: {{ $conversation->getStatusName() }}">
                             @if ($conversation->state != App\Conversation::STATE_DELETED)
-                                <button type="button" class="btn btn-{{ App\Conversation::$status_classes[$conversation->status] }} btn-light conv-info-icon" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-label="{{ __("Status") }}"><i class="glyphicon glyphicon-{{ App\Conversation::$status_icons[$conversation->status] }}"></i></button>
+                                <button type="button" class="btn btn-{{ App\Conversation::$status_classes[$conversation->status] }} btn-light conv-info-icon" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-label="{{ __("Status") }}: {{ $conversation->getStatusName() }}"><i class="glyphicon glyphicon-{{ App\Conversation::$status_icons[$conversation->status] }}"></i></button>
                                 <button type="button" class="btn btn-{{ App\Conversation::$status_classes[$conversation->status] }} btn-light dropdown-toggle conv-info-val" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false" aria-label="{{ __("Status") }}">
                                     <span>{{ $conversation->getStatusName() }}</span> <span class="caret"></span>
                                 </button>
(END)

[fulldecent]

Cool, I see what you did there. Applied, pulled into my PR.

[neosonic2]

Awesome, glad you like the changes. I’m very happy with this first accessibility update to Freescout.

On Jun 28, 2021, at 12:22 PM, William Entriken @.***> wrote:

Cool, I see what you did there. Applied, pulled into my PR.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-869824854, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDFZMT3QZZCVH2J2RA3TVCOWFANCNFSM42WBJFHQ.

[fulldecent]

The first PR in this initiative is merged!

Is there more to achieve in this issue?

[neosonic2]

My apologies for my delayed response on this, it’s been a busy week with my regular day job as a Web developer and system administrator. Anyways, I really love the progress that has been made so far on making Freescout more accessible. A lot of what is left to do in regards to overall accessibility is mostly minor, i.e. adding more ARIA regions around the page, adding headings to more pages (for easier navigation throughout the page), giving labels to icons (that most of the time take the form of links) which are unlabeled, adding correct button roles to elements that don’t have them but should, etc. It’s mostly “quality of life” improvements that help to make either more controls or more parts of the interface itself accessible.

I am willing to make some of these changes and create a pull request this time if that would be desired. To be honest I have never created a pull request in a repository I do not own before so I’ll have to figure out the process, but I am pretty comfortable with Git so it shouldn’t be that difficult.

I appreciate that pull request #1285 was merged as well, and am grateful to all who have contributed to this initiative thus far.

On Jul 7, 2021, at 2:09 PM, William Entriken @.***> wrote:

The first PR in this initiative is merged!

Is there more to achieve in this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-875819117, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDFUQW4QLJLICEOF72TTWSJ6DANCNFSM42WBJFHQ.

[fulldecent]

Great! If you have more diffs that are tested and work, you can send them to me and I'll make a PR of them

[xogium]

Hi, this looks great ! But imo, for it to be really usable it will still take those buttons labels and such.

I just tried the live demo that runs freescout 1.7.13, and although I do see the new field on combo box and the like which is amazing btw, the text field to write the message itself is still not showing up here and you have to randomly type and hope you are not typing in the subject: field.

Other than that, the editor has a bunch of button that are unlabled and I haven't a clue what those do, but accessibility is certainly on the right track !

P.S: I am using the orca screen reader under linux to try this.

[fulldecent]

@xogium thanks for this. PS do you know of an automated tool that can do validation testing for this? It could produce a comprehensive list of all things that need fixing. Then we could do those things and this issue can be slated for good?

[xogium]

Hi, there's Lighthouse.

It might be of help to track down issues, however, I would never exclusively rely on an automated tool to do accessibility improvements.

Just as you do manual testing of UI tweaks for sighted people, so should you do accessibility testing. An automated tool isn't all you will ever need.

[neosonic2]

@xogium is accurate on many of their points. The message/notes editor’s text field does not render as a regular text field so some screen readers may not be able to see it at all, while others, like VoiceOver on macOS (which is what I’m using) see it as a disabled/read-only text field that cannot be edited. Thus, because I am proficient in HTML, I just use the code button in the editor to write HTML in order to compose the message I want to send or the note I want to add, but of course this does not work for everyone and some users may prefer to enter text into the main editor itself.

Speaking of the editor, as stated none of the buttons have labels. However, I believe they have title attributes because I can still see what they are with specific keystrokes to VoiceOver. I am sure these could easily be copied to ARIA label attributes as well so that no unique commands are required to read each button as it is encountered. If the editor is a third party package, however, this may be out of our control as it may be on the developers of that package to update the accessibility of their product. I have used the TinyMCE editor in previous projects I’ve developed with great success from an accessibility standpoint; if the Freescout team ever considers switching editors in the future, this would be a viable option with a lot of features as well.

I agree with @xogium on their assessment of automated accessibility testing tools. The problem with these tools though is that of course they cannot and do not represent how an actual human would interact with a Web page, one reason being they can’t cover the differences between and nuances of every screen reader out there which a human may use. For example, one person may use Orca on Linux while another may use VoiceOver on macOS or NVDA on Windows, and each of these interact with and present elements differently from one another. I think chipping away at discovered accessibility issues (that are for example reported in this thread) may yield the best accessibility improvements..

On Jul 25, 2021, at 10:13 AM, William Entriken @.***> wrote:

@xogium https://github.com/xogium thanks for this. PS do you know of an automated tool that can do validation testing for this? It could produce a comprehensive list of all things that need fixing. Then we could do those things and this issue can be slated for good?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-886208270, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDF7MNWL7NK7JZZCVF3TZQL2FANCNFSM42WBJFHQ.

[xogium]

I definitely second this.

I'd be happy to help you guys try things out, given that I am, possibly the only blind user on linux that plans on using freescout, so far.

[xogium]

With all of this being said, I think there is also a major issue to consider.

Implementing accessibility is all good, really. But if freescout intends to remain accessible, there is some policy that need to be established.

The project manager should be the one going forward with this, and I think noone else could enforce this without their explicit agreement otherwise.

A policy that at a very mimimum asks the author of some patch(s) to alter their work to comply with accessibility guidelines should be implemented. In cases where the author of some patch(s) refuses to comply with this request, the patch should be rejected. This would be to ensure that everything new that gets added to freescout would be accessible right from the start, hopefully. I feel it is very important to do this as soon as possible so that we avoid being stuck under a mountain of new features that are once again unusable to blind people.

[neosonic2]

Agreed - and this would also eliminate the need for someone having to go in to whatever new feature or patch is released just to make it accessible after the fact, which as mentioned can get tedious or time consuming if there are a lot of new features or patches released that are not accessible.

On Jul 25, 2021, at 11:03 AM, xogium @.***> wrote:

With all of this being said, I think there is also a major issue to cnsider.

Implementing accessibility is all good, really. But if freescout intends to remain accessible, there is some policy that need to be established.

The project manager should be the one going forward with this, and I think noone else could enforce this without their explicit agreement otherwise.

A policy that at a very mimimum asks the author of some patch(s) to alter their work to comply with accessibility guidelines should be implemented. In cases where the author of some patch(s) refuses to comply with this request, the patch should be rejected. This would be to ensure that everything new that gets added to freescout would be accessible right from the start, hopefully. I feel it is very important to do this as soon as possible so that we avoid being stuck under a mountain of new features that are once again unusable to blind people.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-886214502, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDEWT42JKU7MWEHYDC3TZQRUPANCNFSM42WBJFHQ.

[philippkraft]

I am currently deploying Freescout for an administrative student-helpdesk at a university. One of the users is blind, and uses the Jaws-Screenreader (2020) on Windows. We are using the German translation of Freescout. Her main problems are the modal dialogs. So far the move, delete and merge dialog boxes from the ticket actions are not working - she cannot access the button to commit the action, instead the screen reader activates the user profile dropdown in the background. "Forward", without the modal dialog, works nicely. Is this problem known with other screen readers? (We will raise the issue with Jaws also, if this is screen reader specific...)

[neosonic2]

I don’t believe this is specific to JAWS or any one particular screen reader, as all of them have excellent support for modal dialogs on Web pages, as long as those dialogs are built correctly. Some sites and Web apps do a great job of that, but unfortunately others have some issues, and it seems like Freescout may be one of them. Using VoiceOver on macOS I have had similar issues with Freescout modals as well, but I haven’t gotten a chance to take a look at the code of the application to see where the problem might lie. Other apps though exhibit similar issues with screen readers (whether they be JAWS or something else) that you mentioned, so it’s definitely not just Freescout that has this problem.

For me, using the TAB key on the keyboard to navigate the Web page (and thus the modal) allowed me to tab to the buttons in the dialog though I could not read the rest of the dialog’s content normally or use the arrow keys to move through the dialog as I would normally move through a regular Web page (or a regular modal dialog). This technique may or may not work for your JAWS user. She could also try activating the PC Cursor mode of JAWS, or even the Virtual PC Cursor mode, to try and navigate that way and see if JAWS better handles the modal in one of those modes.

Alternatively, Non-Visual Desktop Access (NVDA) is an open source Windows screen reader available on Github that I have used with Freescout before and it seems to work relatively well, though I haven’t tested it with modals because I did not encounter them in the application when using it with NVDA.

On Dec 7, 2021, at 5:57 AM, Philipp Kraft @.***> wrote:

I am currently deploying Freescout for an administrative student-helpdesk at a university. One of the users is blind, and uses the Jaws-Screenreader (2020) on Windows. We are using the German translation of Freescout. Her main problems are the modal dialogs. So far the move, delete and merge dialog boxes from the ticket actions are not working - she cannot access the button to commit the action, instead the screen reader activates the user profile dropdown in the background. "Forward", without the modal dialog, works nicely. Is this problem known with other screen readers? (We will raise the issue with Jaws also, if this is screen reader specific...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-987812715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDB6VKFEINKMVJEYLB3UPXR73ANCNFSM42WBJFHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[philippkraft]

@neosonic2 good to know, that we do not need to involve the JAWS support by now.

I have not dived into all of it but this Stack Overflow Question seems to be closely related, yet outdated. According to this document, a modal dialog needs to have the following attributes:

role="dialog"
aria-labelledby="IDREF"
aria-describedby="IDREF"
aria-modal="true"

The aria-describedby and aria-modal are missing. Since aria-modal is new, a workaround is to make sure that "aria-hidden is set to true on each element containing a portion of the inert layer." Instead, the Move dialog by itself is set to aria-hidden="true"

May be worth trying to change aria-hidden to aria-modal here (I will try as soon I have time for that).

https://github.com/freescout-helpdesk/freescout/blob/97fb5678bcfbe02d9c1970c67cc2be5dea7464e4/public/js/main.js#L2115

[neosonic2]

Where in the source code is the modal dialog code located? This will save me from having to hunt around for it as I haven’t messed with this part of Freescout yet.

That post you found is correct though about the attributes that modals need. I would assume that the Freescout modals are not being “shown” properly so to speak, i.e. something about them is still hidden or aria-hidden, at least to screen readers. I want to compare Freescout’s modals to ones that I have built myself for other sites and that I know work well, and then we can figure out what has to be added to those of Freescout to make them more accessible.

On Dec 7, 2021, at 10:40 AM, Philipp Kraft @.***> wrote:

@neosonic2 https://github.com/neosonic2 good to know, that we do not need to involve the JAWS support by now.

I have not dived into all of it but this Stack Overflow Question https://stackoverflow.com/questions/10016433/is-there-a-way-to-do-an-accessible-modal seems to be closely related, yet outdated. According to this document https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html, a modal dialog needs to have the following attributes:

role="dialog" aria-labelledby="IDREF" aria-describedby="IDREF" aria-modal="true" The aria-describedby and aria-modal are missing. Since aria-modal is new, a workaround is to make sure that "aria-hidden is set to true on each element containing a portion of the inert layer." Instead, the Move dialog by itself is set to aria-hidden="true"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freescout-helpdesk/freescout/issues/1150#issuecomment-988043519, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJDEDABLWIQS5BWLRFCKWDUPYTGPANCNFSM42WBJFHQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[freescout-helpdesk]

Where in the source code is the modal dialog code located? This will save me from having to hunt around for it as I haven’t messed with this part of Freescout yet.

https://github.com/freescout-helpdesk/freescout/blob/dist/public/js/main.js#L389

[philippkraft]

Just changing lines 2115 and 2119 did the trick, as my blind collegue confirmed. I will add a PR later or tomorrow afternoon (Europe time).