Another beta, and it’s big!
NVDA 2023.2 Beta 2
We are moving ever closer to NVDA 2023.2! After the release of the first beta, several issues came to light. This week we have released a second beta – NVDA 2023.2 Beta 2 – which should fix these issues. Please do try Beta 2, both to confirm the fixes, and to ensure nothing else has crept in. If you installed Beta 1, NVDA will prompt to update to Beta 2. You can also download NVDA 2023.2 Beta 2 from the release announcement page.
NVDA 2023.2 contains many exciting features. One of the main headline features is the add-on store, but there is much more. NVDA 2023.2 also includes new braille features, commands, and display support. There are also new input gestures for OCR and flattened object navigation, and lots more!
As well as all this, NVDA 2023.2 Beta 2 includes the following changes since Beta 1:
- Updates to translations
- Various minor fixes to the Add-on Store including:
- added a warning dialog when opening the Add-on Store for the first time
- improved handling of externally installed add-ons
- improved handling of translated add-on information
- Gesture and device detection bug fixes for Eurobraille displays
- Bug fix for displaying the Braille category in NVDA preferences
- Bug fix for handling focus changes, notably for Windows Mail
- Bug fix for Braille viewer
- Bug fix for Eloquence where uppercase words were spelled instead of spoken directly
- Minor changes to the User Guide, particularly the temporary copy restrictions section
Reporting errors
Especially during the beta period, we get a lot of questions around the best way to report errors with NVDA. For a problem to get fixed, an issue needs to be created on GitHub. We have tried to make the template easy to use and including helpful prompts in the comments. If you do struggle with it, we’re always open to suggestions, and we’ve got a couple of resources which may help. Brian Vogel is the moderator of the NVDA user group. He brought my attention to a post with some useful information about reporting issues.
The thread starts with suggestions from NVDA contributor Joseph Lee on what is useful when creating an issue. Brian Vogel has also created documents outlining the steps for creating useful issues. There are links to these documents in the thread as well.
The NVDA user group can be useful for getting help with a feature you aren’t sure about. It is important to note that a bug or feature can only be worked on once an issue is created on GitHub about it. If you need more help filing an issue, you can also write to NV Access.
Reporting accessibility issues
While we’re on reporting issues, lets cover reporting accessibility issues in mainstream programs. What do you do if you can’t access features in your favourite audio editor, word processor or CRM software?
There has been an interesting conversation on Mastodon recently about reporting accessibility issues.
The conversation started from a question around whether you should disclose that you are blind when raising an issue? There is no right or wrong answer to that particular question – some prefer to state it up front, others prefer not to.
Some users are worried that they don’t know how the internals of screen readers work to report issues to other companies. That’s ok. In fact, I think the most important thing to do is distil the issue to as simple as possible. Try to note down the steps to reproduce it. If you can articulate the problem, then the developers can work out the code required.
For me, the two key areas of being able to access a program with NVDA, are:
- Being able to get around the program / website with the keyboard, and
- Having the information about what is going on reported to you
In some cases, it may be an issue accessing a feature with the keyboard. The fact you are using a screen reader is not important if someone who isn’t using a screen reader would also hit the same thing trying to access it with the keyboard. If the problem is that there is no keystroke for something, then the person reading the report can reproduce that without even needing to know what a screen reader is.
Where a program uses inaccessible controls, there often isn’t anything we can do from the NVDA side to make it work. The work really must come from the program itself. We may be able to give advice to a company who is keen to improve. There are also lots of freely available resources online. Last In-Process we covered Guy Barker’s sample to demonstrate building accessible apps.
Where the problem is a web page, the issue is almost always with the way the page is written. In this case, if the developer needs help, a web accessibility company is usually best placed to give advice. There are many companies, but Intopia.digital, Deque or WebAIM are three you might start with.
Even more social
As people leave Twitter, there is a proliferation of alternatives becoming popular. Joining in this trend, we are now on two more social media networks. Many NV Access users are quite active on Mastodon, and we were early adopters of that platform. Mastodon also provides the most accessible user experience. You can join Mastodon here. We are also on RBlind on Lemmy, where many of the r/Blind community formerly on Reddit have moved. To ensure we are available where any of our users or supporters may be, NV Access is now also on Threads and Bluesky. Threads, like Instagram isn’t actually available on a PC.
That’s all for this week. Do try out NVDA 2023.2 Beta 2. Let us know how you find it. Please do report any issues you find on GitHub. We’ll be back with more on NVDA 2023.2 soon!