Vincent Le Goff <vincent.legoff.srs@...>
I think contacting the owner to report accessibility bugs can be done by anyone, and should be done whenever possible. The most important reasons are that fixing the accessibility error will fix for everyone at the same time. And the web developer will know about it. I'm convinced that web developers don't really think about accessibility unless they are reminded that not all users have a mouse or a screen to browse the web. So with the web developer's knowledge, updates to the web application will hopefully maintain the fix, whereas a way to script NVDA will probably not work the next time the web app updates... and web apps, as a rule, tend to update a lot and without warning or notices, which for us certainly adds to the fun. It might not be easy to reach the web developer, but whenever possible I prefer to send a rather long and descriptive accessibility report. Sometimes it works. Often they promise fixes that never come and I feel like sending reminders a year or so later. Sometimes I get no answer. But let's focus on the ones that actually update in a positive way! Besides, I pointed out web apps are trendy these days, but accessibility is gaining some weigh too and web developers feel like they have less ground refusing their help whenever we ask them.
toggle quoted messageShow quoted text
On 10/13/2019 4:39 AM, Sean Murphy wrote:
If the web app you are using is independent of a browser. In other word is self-contained browser like skype, Visual Code Editor and others. Then what is available to you is very restrictive. As the screen reader is fully dependent on what is revealed by this style of app via the accessibility framework like UIA, MSAA or iaccess2. If you cannot write a plugin, then you will have very limited access to available information.
A general overview how web pages regardless if they are stand-alone apps or uses any web browser work:
* the web page is loaded.
* The DOM is populated (Document Object Model).
* the accessibility tree of the browser is populated which has the required information for a assistive technology product.
* The accessibility API (framework) like UIA is populated by the browser.
* the screen reader then interrogates the accessibility API or the browser directly.
There is more complexity to what I have outlined above. But this gives a general overview how information flows.
NVDA might be able to get more information but you need to learn python, the accessibility API and possibly a bunch of other API information to get the information you want. A major learning curve for yourself. Where it would be far cost effective for your energy and time to reach out to the owner of the product to make the require changes.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Damien Garwood
Sent: Sunday, 13 October 2019 7:16 AM
Subject: Re: [nvda] Are web applications that accessible?
Those are actually very interesting questions. I have theories, but that's all they are. I'm sure someone who is more expert on this topic will correct me if it turns out I'm wrong, which I'm sure I probably am.
The simple answer first. Announcements for several document elements (table headers, clickable items, links, headings etc) can be enabled or disabled through the document formatting section of the settings dialog.
Other than that, the only way to really customise what is spoken by NVDA (such as changing control type text, changing spoken order etc) is through scripting.
Now for my theories. Scripting web app enhancements with NVDA wouldn't be as simple as making an app module for several reasons.
1. NVDA has its own internal stuff that allows it to do its browse/focus mode thing. This could interfere with web apps that you might think can be scripted as app modules (those packaged as executables like Skype and so on).
2. The web browser is just a host for the app, and so I'm guessing NVDA can't get to it the same way it gets to a standard desktop control. Even apps packaged as their own executables like Skype are actually using Chrome/Chromium/whatever it's called these days.
3. Bear in mind that different browsers have different rules for rendering controls and information, and so unfortunately it wouldn't be a uniform process.
Having said that. There are several accessibility API's that NVDA has, over the years, managed to smack under one umbrella. So I'm guessing that's only a matter of time before the same can be done for web browsers, and eventually, web apps.
As for profiles. My guess is that those can be used in the normal way for web apps that come as executables, but would be difficult to set up for external websites, for similar reasons. The profile would be triggered by the browser, not the app itself.
On 12/10/2019 07:21 pm, Robert Logue wrote:
1: Is it difficult for users to script NVDA for web applications?
2: Is there a standard way to customize what is spoken?
3: Does NVDA have a way to set up individual profiles for each web
On 2019-10-07 8:51 a.m., Gene wrote:
So, how do you skip all that? I don't use GMail on the Internet
except to look at the spam filter now and then. I am not familiar
with the supplied short cuts. But any time you want to jump from
message to message, typing x in browse mode takes you to the check
box for the next message. You hear, as I recall, the subject line
and the name of the sender.
But there are ways of skipping unwanted material and the fact that
they are not well known indicates poor training or poor training
materials being widely used.
The find command is one of the most useful but under or unused
feature. What is the last consistent line before the message text,
or the synopsis, begins? Find it by looking from the check box down
on more than one message. You will see a pattern.
Do a search for that line and you can then do the following:
x to move to the next message.
Repeat search, you have already searched once by entering the search
string, then down arrow once and read to end.
After you do this enough to have it become second nature, it will be
reasonably fast and efficient.
You can't be a good Internet user in more complex areas of a web page
if you rely on what I refer to as "the kindness of strangers.", as is
famously said by a character in A Street Car Named Desire.
The number of blind people, even those who are generally good
computer users, who don't know how to do what I'm describing is clear
evidence of the inadequate and poor training received.
I don't use web applications enough to discuss the general questions
presented here, but GMail isn't a web application in the sense that
Google Docx (spelling) is. It is a layout but you aren't working
with an application embedded in the page.
And you will see lots of times when doing things such as I describe
is important for efficient navigation.
----- Original Message -----
*From:* Devin Prater <mailto:email@example.com>
*Sent:* Monday, October 07, 2019 8:44 AM
*To:* firstname.lastname@example.org <mailto:email@example.com>
*Subject:* Re: [nvda] Are web applications that accessible?
On no, it says “Reply, reply all, forward…” all that, even if you use
the keyboard commands to move to the next or previous message.
On Oct 7, 2019, at 8:14 AM, Hope Williamson <firstname.lastname@example.org<mailto:email@example.com>> wrote:
There's no reason to leave out normal header information. In otherwords, the sender, date, time, and the fact that it's from you. If
it's like the IP you're referring to, then that's different.