irineu333 / speaktouch Goto Github PK

• Implement automatic versionName and versionCode
• Implement publish keystore
• Migrate gradle configuration from Groovy to KTS ¹

Study a way to automate testing.

Type detection based on class name is rudimentary and needs to be improved.

• Improve type detection.
• Extract and localize text.

The Speak Touch must be licensed under the GNU GPLv3 license. Everyone is free to modify and/or redistribute it, as long as the redistribution includes the source code (or a link to it).

• Include a license in the project
• Include the license and copyright notice in all source files ¹
• Include the license notice in the README file

Implement haptic feedback when exploring the screen.

The context menu should have functions related to the selected element, and the options depend on the element's properties.

Editable

• Paste
• Speak (Speech To Text)
• Clear

Readable

• Copy

Checkable

• Enable/Disable

Clickable

• Click

Long Clickable

• Long click

Implement a feature to pause a speech and resume where you left off. The default gesture is to tap with two fingers.

Just like Talkback and Jieshou, SpeakTouch should be able to re-read the focused view

Note: This feature cannot interfere with #66

Implement gesture detection.

Simple

• Right
• Left
• Up
• Down

Compound

• Up, Down
• Up, Right
• Up, Left
• Down, Up
• Down, Right
• Down, Left

Describe the bug:

Testing in the Threads app, made in JetPack Compose, I noticed that SpeakTouch is not focusing on the follow button in the profile suggestions to follow.

To Reproduce:

Open the Threads app, and navigate to "suggestions for you", try focusing on the follow button within each suggestion card.

Evidence: SpeakTouch

Expected behavior

You should focus on the follow button, just like with Jeishou and Talkback.

Evidence: Jeishou

More infos:

App version: 1.0.0 - DEV
Android version: 12
Device: Moto G30

Currently, SpeakTouch cannot read web content either from Chromium-based web browsers nor Firefox-based ones.

Interacting with web components (texts, alternate descriptions for images, links, buttons, clickable elements, combo boxes, checkboxes [form elements] etc.) maybe challanging to implement; for MVP let it just announce the content.

Speak Touch is crashing during touch exploration.

Describe the bug:

I discovered this bug by browsing the YouTube community tab post, if you find a post with a description long enough to need to expand, SpeakTouch will focus on a non-readable ViewGrop and simply say nothing.

To Reproduce:

Find a post with a long description on YouTube communities.

Expected behavior

It should focus on the Text View, which has the action of expanding, like talkback and jeishou.

Screenshots:

Speak Touch

Layout

It shouldn't focus	It should focus

Talkback behavior

Stack trace (to dev):

No have

More infos:

App version: 1.0.0 - DEV
Android version: 12
Device: Motorola G30

Implement touch exploration through accessibility focus.

Speak the content of the focused item.

Probably due to the correction "not focusing on inner text" #5 , Speak Touch is not focusing on texts that it should be focusing on because it falls into Priority 1 due to an actionable ancestor.

Speak Touch	Talkback

We need to distinguish situations like this, where the focus should go to the texts, from situations such as a button with internal text. One clue is the fact that Talkback does not allow focusing on the dialog container.

• Next element
• Previous element
• Next title
• Previous title

Use accessibility volume on devices Android 8.0 (api 26) or higher.

You are only reading the description

To revise and refactor the node reading system.

Note: Use Talkback's behavior as a parameter, since it is also a reference for developers.

"Screen Reader" was a provisional name. After considering other names, it was decided that the name of the app will be "Speak Touch", especially since I recently discovered that there is already a screen reader app called "Screen Reader".

Therefore, the name and package of the app should be changed to "Speak Touch" and "com.neo.speaktouch".

Play Store title

English

Speak Touch - Screen reader for blind

Português

Speak Touch - Leitor de tela para cegos

Describe the bug:

In notifications, the app is not focusing on the WhatsApp notification card, instead it is only focusing on its content when expanded

To Reproduce:

Receive a WhatsApp message, open the settings and focus it

Evidence: SpeakTouch

Expected behavior

It should focus on the notification card, just like Talkback and Jieshou

Evidence: Talkback

More infos:

App version: 1.0.0 - DEV
Android version: 12
Device: Moto G30

Speak Touch is not focusing on buttons when hovering, only when clicking or navigating. Additionally, it is focusing on the inner texts, a behavior that is not seen in Talkback and Jieshuo.

Wrong

1. Not focusing on buttons when hovering.
2. Focusing on inner text, a behavior not seen in Talkback and Jieshuo.

Correct

1. Focusing on buttons when hovering.
2. Not focusing on inner text.

Speak Touch	Talkback

Observations

1. While conducting usability tests, I noticed that sometimes it would focus on the button. Ran more tests and I realized that the chances of it happening increased if we moved our finger very quickly.
2. When the hovering ends, it always focuses on the button.

Alguns pontos que podem ser melhorados no app

• Rodar interceptadores em paralelo (performance)
• Cache na verificação do tipo da classe (performance)
• Abstrair regras de foco (legibilidade)
• Otimizar verificação que envolve grandes inteirações (performance)
• Remove logs que usam funções pesadas

• speak app name
• speak screen name

Comparing to Talkback, some behaviors of Speak Touch don't seem correct regarding containers.

Context:
Consider container ViewGroup whose what matters to us are their children. When a node with children meets the criteria to be focusable by accessibility but doesn't have text or contentDescription, the SpeechInterceptor reads its children. This solves the problem of custom buttons, such as CardView with TextView inside.

Problem:
I couldn't fully understand the Talkback criteria, so I created my own through trial and error, and due to that, some behaviors are different from Talkback. From these different behaviors, I identified two that seem wrong.

1. It's not reading some nodes with isCheckable inside containers when they don't have text or contentDescription. This is wrong and Talkback is able to read them.

2. It's reading focusable nodes inside containers. Talkback doesn't do that, and I believe it's because these nodes can be individually explored.