Date   

Re: About QT4 accessibility

Sean
 

Unfortunately, the level of accessibility of QT programs is very variable.
For example, while I can use VLC very accessible, I cannot use the application built with another qt5.

I can not understand why this is due.
Sometimes one of the programs in the same version is accessible while the other is not.

QT is a very popular library.
I hate not being able to use most programs.

I hope there is something NVDA can do about this.

On 17/05/2020 10:36, Alberto Buffolino wrote:
Hi all,
main question: is there a qtaccessiblewidgets4.dll publicly available and redistributable?
Explanation: in these years I have encountered many programs with QT4 GUI - the old Calibre, SPFlashTool (familiar to Android modders), Lightscreen, Lazesoft Recovery Suite, and others that I forgot - for which putting that DLL in a folder called "accessible" in their main path magically turns them from completely inaccessible to at least usable... but I got this DLL from an old Kindle for PC installation, so it obviously signed by Amazon LLc, that sounds very bad for my previous question. 😅
If there is a way to compile a generic version, I'm thinking, maybe we could make an add-on for this situation, or even include it in NVDA directly, like which was done for JAB...
I know that with QT5 the situation is better, but in my experience QT4 is still largely present and, unfortunately, often in software quite specialised.
Just a thought...
Alberto



--

Sean

I’m student and programmer. I write often Python, sometimes Go and rarely C++.
I can understand Turkish and English.


About QT4 accessibility

Alberto Buffolino
 

Hi all,
main question: is there a qtaccessiblewidgets4.dll publicly available and redistributable?
Explanation: in these years I have encountered many programs with QT4 GUI - the old Calibre, SPFlashTool (familiar to Android modders), Lightscreen, Lazesoft Recovery Suite, and others that I forgot - for which putting that DLL in a folder called "accessible" in their main path magically turns them from completely inaccessible to at least usable... but I got this DLL from an old Kindle for PC installation, so it obviously signed by Amazon LLc, that sounds very bad for my previous question. 😅
If there is a way to compile a generic version, I'm thinking, maybe we could make an add-on for this situation, or even include it in NVDA directly, like which was done for JAB...
I know that with QT5 the situation is better, but in my experience QT4 is still largely present and, unfortunately, often in software quite specialised.
Just a thought...
Alberto


NVDA add-on: Developer toolkit 20.04 is released

Andy B.
 

Hi,

 

The NVDA add-on, Developer toolkit 20.04 has been released. You can read about and download it below.

https://github.com/ajborka/nvda_developer_toolkit/releases/tag/20.04

 

 

Sent from Mail for Windows 10

 


Re: Any chance of compiling NVDA with VSCode?

Marlon Brandão de Sousa
 

Objectively speaking VSCode can use Microsoft c++ compiler as its c++ backend.


You would need to make sure all the needed components (header files, libs, DLLs and others) that Visual Studio installs automatically when you choose to install some components are installed and in folders that the c++ compiler can access and you would need to make sure that the commands scons perform such as midl and others are available in non visual studio installations.


Discovering which of them are available in the Microsoft c++ compiler installation itself and which are Visual Studio wrappers might take some time.


In general, you can use vscode to edit the c++ files. Things such as intelicense and others should work relatively but all of this in a computer where Visual Studio and dependencies are already installed.


If you want to go for non Visual Studio installs you would need to collect all dependencies Visual Studio installs and install by your self and make sure the version of the platform sdk NVDA uses and Visual c++ compiler are installed and probably play with scons scripts, which deserve their own section of experimentation in order to figure out.


This would be a huge thing to do.


Personally, I would like to have an automated way of having dlls compiled for a given commit by a build machine, because this would allow users with computers not able to run
Visual Studio to run NVDA locally. The vast majority of NVDA contributors do not need to play with the c++ code and it is probable that potential contributors from parts of the world where having a computer good enough to run VS 2019 (a very heavy package) is not so easy are probably blocked from contributing, even if they need to change only python.


The many many giga bites of storage that ARM related SDKs use might be an issue, even one having Visual Studio, because if they are only changing python they wouldn't need to compile arm to run locally, only x86 and x64.


Now that we have github actions may be we can generate pre compiled DLLs for every commit on master and allow folks just to download the package ratter than having to compile them all if they don't need or can not afford to compile them for whatever reason and need, never-the-less, run locally.

On 09/05/2020 20:04, James Scholes wrote:
Pretty sure VS Code is Visual Studio in name only.  I.e. it's not a stripped down version of Visual Studio, it's a completely different codebase and application.  NVDA needs access to components which ship with Visual Studio, rather than the IDE itself, so this isn't likely to make sense.

Regards,

James Scholes

On 09/05/2020 at 6:00 pm, Alex Hall wrote:
Hey all,
The official way to compile NVDA is with Visual Studio. I've never used that application seriously, but in the last few months, I've come to really enjoy using VSCode. Is there any chance that NVDA could be compiled with VSCode instead of the full-blown Visual Studio application?

--
Alex Hall
Automatic Distributors, IT department
ahall@... <mailto:ahall@...>


Re: Any chance of compiling NVDA with VSCode?

Alex Hall
 

Thanks for the responses, everyone. Joel, I'll give that a shot and see what happens.

I didn't really consider the libraries and packages VS installs, but it makes sense now that people point it out. After all, to make something like NVDA into an executable, it needs a bunch of DLLs for WX and other components. I remember running into some really weird problems when running py2exe on anything using WX, where I had to locate specific versions of DLL files before the packager gave me a valid executable. I guess I figured all that would be included in the code base, but it also makes sense to just rely on the IDE to provide the right files in the right places.


On Mon, May 11, 2020 at 9:34 AM Joel <Joeldodson@...> wrote:
Hi guys,

I've only recently started trying VSCode so don't take what I say as gospel...

VSCode is in the fancy code editor space as opposed to being a traditional IDE like Visual Studio or Eclipse or InteliJ or pick your poison.  It's based on ElectronJS.  It has nothing to do with the Visual Studio code base.  If you want to develop in languages other than Javascript running on NodeJS (and I think it natively supports Typescript as well), you need to install plugins.  Python, for example, is one of the most popular plugins.

Alex, look in the main github repo for NVDA, https://github.com/nvaccess/nvda, and search for "VSCode".  It will take you to a section of the readme.md describing how to install some configuration to use VSCode for NVDA development.  You'll still need to install Visual Studio Community Edition with all the packages listed in the readme.md.  I haven't tried this but would be surprised if it doesn't work.

Cheers, Joel


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via groups.io
Sent: Sunday, May 10, 2020 12:41 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Any chance of compiling NVDA with VSCode?

So what is vs code for then? Just a quick and dirty way of writing small projects?
 Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "James Scholes" <james@...>
To: <nvda-devel@groups.io>
Sent: Sunday, May 10, 2020 12:04 AM
Subject: Re: [nvda-devel] Any chance of compiling NVDA with VSCode?


> Pretty sure VS Code is Visual Studio in name only.  I.e. it's not a
> stripped down version of Visual Studio, it's a completely different
> codebase and application.  NVDA needs access to components which ship with
> Visual Studio, rather than the IDE itself, so this isn't likely to make
> sense.
>
> Regards,
>
> James Scholes
>
> On 09/05/2020 at 6:00 pm, Alex Hall wrote:
>> Hey all,
>> The official way to compile NVDA is with Visual Studio. I've never used
>> that application seriously, but in the last few months, I've come to
>> really enjoy using VSCode. Is there any chance that NVDA could be
>> compiled with VSCode instead of the full-blown Visual Studio application?
>>
>> --
>> Alex Hall
>> Automatic Distributors, IT department
>> ahall@... <mailto:ahall@...>
>>
>
>
>










--
Alex Hall
Automatic Distributors, IT department
ahall@...


Re: Any chance of compiling NVDA with VSCode?

Joel
 

Hi guys,

I've only recently started trying VSCode so don't take what I say as gospel...

VSCode is in the fancy code editor space as opposed to being a traditional IDE like Visual Studio or Eclipse or InteliJ or pick your poison. It's based on ElectronJS. It has nothing to do with the Visual Studio code base. If you want to develop in languages other than Javascript running on NodeJS (and I think it natively supports Typescript as well), you need to install plugins. Python, for example, is one of the most popular plugins.

Alex, look in the main github repo for NVDA, https://github.com/nvaccess/nvda, and search for "VSCode". It will take you to a section of the readme.md describing how to install some configuration to use VSCode for NVDA development. You'll still need to install Visual Studio Community Edition with all the packages listed in the readme.md. I haven't tried this but would be surprised if it doesn't work.

Cheers, Joel

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via groups.io
Sent: Sunday, May 10, 2020 12:41 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Any chance of compiling NVDA with VSCode?

So what is vs code for then? Just a quick and dirty way of writing small projects?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "James Scholes" <james@...>
To: <nvda-devel@groups.io>
Sent: Sunday, May 10, 2020 12:04 AM
Subject: Re: [nvda-devel] Any chance of compiling NVDA with VSCode?


Pretty sure VS Code is Visual Studio in name only. I.e. it's not a
stripped down version of Visual Studio, it's a completely different
codebase and application. NVDA needs access to components which ship with
Visual Studio, rather than the IDE itself, so this isn't likely to make
sense.

Regards,

James Scholes

On 09/05/2020 at 6:00 pm, Alex Hall wrote:
Hey all,
The official way to compile NVDA is with Visual Studio. I've never used
that application seriously, but in the last few months, I've come to
really enjoy using VSCode. Is there any chance that NVDA could be
compiled with VSCode instead of the full-blown Visual Studio application?

--
Alex Hall
Automatic Distributors, IT department
ahall@... <mailto:ahall@...>


Re: Any chance of compiling NVDA with VSCode?

Brian's Mail list account
 

So what is vs code for then? Just a quick and dirty way of writing small projects?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "James Scholes" <james@...>
To: <nvda-devel@groups.io>
Sent: Sunday, May 10, 2020 12:04 AM
Subject: Re: [nvda-devel] Any chance of compiling NVDA with VSCode?


Pretty sure VS Code is Visual Studio in name only. I.e. it's not a stripped down version of Visual Studio, it's a completely different codebase and application. NVDA needs access to components which ship with Visual Studio, rather than the IDE itself, so this isn't likely to make sense.

Regards,

James Scholes

On 09/05/2020 at 6:00 pm, Alex Hall wrote:
Hey all,
The official way to compile NVDA is with Visual Studio. I've never used that application seriously, but in the last few months, I've come to really enjoy using VSCode. Is there any chance that NVDA could be compiled with VSCode instead of the full-blown Visual Studio application?

--
Alex Hall
Automatic Distributors, IT department
ahall@... <mailto:ahall@...>


Re: Any chance of compiling NVDA with VSCode?

James Scholes
 

Pretty sure VS Code is Visual Studio in name only. I.e. it's not a stripped down version of Visual Studio, it's a completely different codebase and application. NVDA needs access to components which ship with Visual Studio, rather than the IDE itself, so this isn't likely to make sense.

Regards,

James Scholes

On 09/05/2020 at 6:00 pm, Alex Hall wrote:
Hey all,
The official way to compile NVDA is with Visual Studio. I've never used that application seriously, but in the last few months, I've come to really enjoy using VSCode. Is there any chance that NVDA could be compiled with VSCode instead of the full-blown Visual Studio application?
--
Alex Hall
Automatic Distributors, IT department
ahall@... <mailto:ahall@...>


Any chance of compiling NVDA with VSCode?

Alex Hall
 

Hey all,
The official way to compile NVDA is with Visual Studio. I've never used that application seriously, but in the last few months, I've come to really enjoy using VSCode. Is there any chance that NVDA could be compiled with VSCode instead of the full-blown Visual Studio application?

--
Alex Hall
Automatic Distributors, IT department
ahall@...


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Noelia Ruiz
 

Hello:

Imo, the approach chosen in the current project is good. For me,
trying to recognize images and objects is not contradictory with
common or less frequent interfaces, since images can be associated or
contain long pieces of text (which we could understand as a common
interface like readonly edit box or a document), with links, buttons
(for example sometimes OCR can be used to activate buttons of a dialog
in an inaccessible program), or even several of these kind of
controls, such as image maps in webpages.
I think that developers need to provide semantic information and
screen readers can use this throught known apis and standards like
HTML, to show headings for example, so we can navigate with h key.
Of course images, the same as audio transcriptions and maybe other
elements, need to be correctly described and human and manual
activities are likely required to produce an accurate result to be
presented in screen readers. But this is not always possible, so I
think that this project goes in the right way, since this doesn't mean
that images are not used as commont elements of interfaces. I think
images and its objects and text can be contained in these elements, so
this is not a separate or a different thing respect common elements,
but a subset of them and text is better recognized, so detecting the
content of images for me is right.
Regards

2020-05-09 17:09 GMT+02:00, Rui Fontes <rui.fontes@...>:

I agree! Such technic and, perhaps an attempt to decipher the control
name given by the developer, will make the use of some programs much
easier!


Rui Fontes


Às 12:56 de 09/05/2020, Marlon Brandão de Sousa escreveu:

I would focus instead on common interface elements recognition, for
example buttons, checkboxes, label associations and etc.


Although less glamorous with the final user, for me screen readers
will have to use this approach sooner or latter because nobody can
keep up with the pace of technology and accessibility will be each
time more broken in the sense that the time new technology arises and
the time they keep up with accessibility before being replaced by
newer technology is inversely proportional, which means that the time
between one technology becoming accessibility mature and being
replaced by newer imature technology will be each time smaller while
the time for new technology to become mature in terms of accessibility
will be equals or greater than it is today, given that more resources
tend to be allocated in new stuff development than in becoming current
stuff mature.


This is a marketing tendency and there is nothing we can do about it,
think about how accessibility and usability as a whole has decreased
in Apple systems because the pressure to release new features is
imposed by the marketing and each time greater.


Today Microsoft is spending lots of resources in accessibility. This
has made lives of screen readers for Windows easier than ever, but who
knows how much time this will least. It might be forever, it might be
for six months before the company redirects efforts to other
priorities. What if a foreign company arises and starts imposing
pressure for new stuff on Microsoft for Windows matters, just like the
marketing is moving faster and faster on the mobile arena?


Fact of life is the only thing we can assume that will be considered
are the visual interfaces for sighted people. These will never become
inaccessible to the sighted for obvious reasons and my understanding
is that they are standardized enough to be recognizable (a button is
relatively the same in qt, gtk, win32, windows forms or exposed by a
remote desktop screen) because people can recognize it as a button and
when it is clicked it behaves like a button. If sighted people can
recognize it as a button, then should image recognition IA, because
unless screen readers start to use a IA approach they won't be able to
resist in the long run.


Of course this doesn't solve all the possible problems, system focus,
context information, OS events and such wouldn't be but at least one
could focus more on scripts to correlation stuff than on querying apps
to extract visual element descriptions, which ultimately depends on
developers that, history shows, are usually either because they lack
knowledge, resources or will, unable to keep up in time.


On 05/05/2020 15:49, @ShubhamJain wrote:
Thank you for the introduction Reef!

I am very excited to be working on this project and getting to know
the community better! As Reef mentioned, you can find details about
the project at the above link or you can just contact me.

The ultimate goal of this project is to help and benefit the
community and users, and so, I would love any and all feedback, tips
and guidance you might have to offer!
It will not be possible for this project to be a success without your
input!

Looking forward to working with all of you!

regards,
Shubham Jain



Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Rui Fontes
 

I agree! Such technic and, perhaps an attempt to decipher the control name given by the developer, will make the use of some programs much easier!


Rui Fontes


Às 12:56 de 09/05/2020, Marlon Brandão de Sousa escreveu:

I would focus instead on common interface elements recognition, for example buttons, checkboxes, label associations and etc.


Although less glamorous with the final user, for me screen readers will have to use this approach sooner or latter because nobody can keep up with the pace of technology and accessibility will be each time more broken in the sense that the time new technology arises and the time they keep up with accessibility before being replaced by newer technology is inversely proportional, which means that the time between one technology becoming accessibility mature and being replaced by newer imature technology will be each time smaller while the time for new technology to become mature in terms of accessibility will be equals or greater than it is today, given that more resources tend to be allocated in new stuff development than in becoming current stuff mature.


This is a marketing tendency and there is nothing we can do about it, think about how accessibility and usability as a whole has decreased in Apple systems because the pressure to release new features is imposed by the marketing and each time greater.


Today Microsoft is spending lots of resources in accessibility. This has made lives of screen readers for Windows easier than ever, but who knows how much time this will least. It might be forever, it might be for six months before the company redirects efforts to other priorities. What if a foreign company arises and starts imposing pressure for new stuff on Microsoft for Windows matters, just like the marketing is moving faster and faster on the mobile arena?


Fact of life is the only thing we can assume that will be considered are the visual interfaces for sighted people. These will never become inaccessible to the sighted for obvious reasons and my understanding is that they are standardized enough to be recognizable (a button is relatively the same in qt, gtk, win32, windows forms or exposed by a remote desktop screen) because people can recognize it as a button and when it is clicked it behaves like a button. If sighted people can recognize it as a button, then should image recognition IA, because unless screen readers start to use a IA approach they won't be able to resist in the long run.


Of course this doesn't solve all the possible problems, system focus, context information, OS events and such wouldn't be but at least one could focus more on scripts to correlation stuff than on querying apps to extract visual element descriptions, which ultimately depends on developers that, history shows, are usually either because they lack knowledge, resources or will, unable to keep up in time.


On 05/05/2020 15:49, shubhamdjain7@... wrote:
Thank you for the introduction Reef!

I am very excited to be working on this project and getting to know the community better! As Reef mentioned, you can find details about the project at the above link or you can just contact me.

The ultimate goal of this project is to help and benefit the community and users, and so, I would love any and all feedback, tips and guidance you might have to offer!
It will not be possible for this project to be a success without your input!

Looking forward to working with all of you!

regards,
Shubham Jain


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Marlon Brandão de Sousa
 

I would focus instead on common interface elements recognition, for example buttons, checkboxes, label associations and etc.


Although less glamorous with the final user, for me screen readers will have to use this approach sooner or latter because nobody can keep up with the pace of technology and accessibility will be each time more broken in the sense that the time new technology arises and the time they keep up with accessibility before being replaced by newer technology is inversely proportional, which means that the time between one technology becoming accessibility mature and being replaced by newer imature technology will be each time smaller while the time for new technology to become mature in terms of accessibility will be equals or greater than it is today, given that more resources tend to be allocated in new stuff development than in becoming current stuff mature.


This is a marketing tendency and there is nothing we can do about it, think about how accessibility and usability as a whole has decreased in Apple systems because the pressure to release new features is imposed by the marketing and each time greater.


Today Microsoft is spending lots of resources in accessibility. This has made lives of screen readers for Windows easier than ever, but who knows how much time this will least. It might be forever, it might be for six months before the company redirects efforts to other priorities. What if a foreign company arises and starts imposing pressure for new stuff on Microsoft for Windows matters, just like the marketing is moving faster and faster on the mobile arena?


Fact of life is the only thing we can assume that will be considered are the visual interfaces for sighted people. These will never become inaccessible to the sighted for obvious reasons and my understanding is that they are standardized enough to be recognizable (a button is relatively the same in qt, gtk, win32, windows forms or exposed by a remote desktop screen) because people can recognize it as a button and when it is clicked it behaves like a button. If sighted people can recognize it as a button, then should image recognition IA, because unless screen readers start to use a IA approach they won't be able to resist in the long run.


Of course this doesn't solve all the possible problems, system focus, context information, OS events and such wouldn't be but at least one could focus more on scripts to correlation stuff than on querying apps to extract visual element descriptions, which ultimately depends on developers that, history shows, are usually either because they lack knowledge, resources or will, unable to keep up in time.


On 05/05/2020 15:49, shubhamdjain7@... wrote:
Thank you for the introduction Reef!

I am very excited to be working on this project and getting to know the community better! As Reef mentioned, you can find details about the project at the above link or you can just contact me.

The ultimate goal of this project is to help and benefit the community and users, and so, I would love any and all feedback, tips and guidance you might have to offer!
It will not be possible for this project to be a success without your input!

Looking forward to working with all of you!

regards,
Shubham Jain


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

 

Hi,

His name is Oliver and email address is oliver.edholm@.... Also, if you want to introduce yourself to add-ons community, the NVDA Add-ons list can be found at:

https://nvda-addons.groups.io/g/nvda-addons

 

I advise talking to Oliver first so he can give you some feedback about the proposal.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Shubham Jain
Sent: Thursday, May 7, 2020 10:54 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing our Google Summer of Code 2020 student: Shubham Jain

 

Hello again Joseph,

I would love to talk to the author of the add-on! I would be very grateful if you could connect me to him.
Thank you so much!

regards,
Shubham Jain

_._,_._,_


Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#45022) | Reply To Group | Reply To Sender | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [joseph.lee22590@...]

_._,_


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Shubham Jain
 

Hello again Joseph,

I would love to talk to the author of the add-on! I would be very grateful if you could connect me to him.
Thank you so much!

regards,
Shubham Jain


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

 

Hi,

I see. In this case, would you like to talk to the author of this add-on (unless you already talked to the author) to get some advice and early feedback? If yes, I’ll forward this conversation to NVDA add-ons list.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Shubham Jain
Sent: Thursday, May 7, 2020 10:41 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing our Google Summer of Code 2020 student: Shubham Jain

 

Hello Joseph!

Image Describer is a big inspiration for this project.


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Shubham Jain
 

Hello Joseph!

Image Describer is a big inspiration for this project.


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Shubham Jain
 

Hi Pawel!

Yes, chrome already supports getting image descriptions and it is amazing! Given the amount of resources companies like Google has at their disposal, it is impossible for our models to be as good but I think it is a step in the right direction. We can always improve any implementation in the future when computation is easier. Besides, it is always best to not rely on 3rd party services as their terms might change. With an inbuilt implementation, we can provide this function in not just chrome but other browsers  and with local photo-viewing apps!


Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

 

Hi,
Image Describer used to be a useful NVDA add-on for this purpose until things changed.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Pawel Urbanski
Sent: Thursday, May 7, 2020 7:05 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing our Google Summer of Code 2020 student: Shubham Jain

If only Chrome did not have this feature already. You just tell it to automatically get descriptions for images that have no alt attribute specified...


On 07/05/2020, enes sarıbaş <enes.saribas@...> wrote:
Hello Shubham,

Even a few cases I believe could possibly cover all or most of the
capchas outside of google with no audio. Therefore, I believe this
would make the lives of NVDA users even better with such a feature.

I wish you the best on your project

Enes

On 5/7/2020 1:47 AM, Shubham Jain wrote:
Hello Enes,

Thank you for your interest in my project!
There has been a lot of research and work on solving captchas using
ML techniques and it is certainly possible. However, these models are
specific to the types of captchas they have been trained on and will
not work with other types. I understand that having it work in only a
few specific cases is still a big advantage. Hopefully, Google's
Captcha v3 will do away with this problem entirely, as it does not
rely on any explicit user input.
Yours is a brilliant idea nonetheless and definitely one to look into!

regards,
Shubham Jain



Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

Pawel Urbanski
 

If only Chrome did not have this feature already. You just tell it to
automatically get descriptions for images that have no alt attribute
specified...

On 07/05/2020, enes sarıbaş <enes.saribas@...> wrote:
Hello Shubham,

Even a few cases I believe could possibly cover all or most of the
capchas outside of google with no audio. Therefore, I believe this would
make the lives of NVDA users even better with such a feature.

I wish you the best on your project

Enes

On 5/7/2020 1:47 AM, Shubham Jain wrote:
Hello Enes,

Thank you for your interest in my project!
There has been a lot of research and work on solving captchas using ML
techniques and it is certainly possible. However, these models are
specific to the types of captchas they have been trained on and will
not work with other types. I understand that having it work in only a
few specific cases is still a big advantage. Hopefully, Google's
Captcha v3 will do away with this problem entirely, as it does not
rely on any explicit user input.
Yours is a brilliant idea nonetheless and definitely one to look into!

regards,
Shubham Jain



Re: Introducing our Google Summer of Code 2020 student: Shubham Jain

enes sarıbaş
 

Hello Shubham,

Even a few cases I believe could possibly cover all or most of the capchas outside of google with no audio. Therefore, I believe this would make the lives of NVDA users even better with such a feature.

I wish you the best on your project

Enes

On 5/7/2020 1:47 AM, Shubham Jain wrote:
Hello Enes,

Thank you for your interest in my project!
There has been a lot of research and work on solving captchas using ML techniques and it is certainly possible. However, these models are specific to the types of captchas they have been trained on and will not work with other types. I understand that having it work in only a few specific cases is still a big advantage. Hopefully, Google's Captcha v3 will do away with this problem entirely, as it does not rely on any explicit user input.
Yours is a brilliant idea nonetheless and definitely one to look into!

regards,
Shubham Jain