Hi, as a registered blind person who uses an IPhone to access the Naim app with VoiceOver (the built in screen reader for Macs). Does any testing of the Naim app for accessibility happen? I only ask as many of the controls don’t seem to be labelled properly, and there’s a lack of headings and containers which would aid navigation of the app enormously. Any feedback would be greeted with interest. If anyone would like to find out how a blind person uses an IPhone, just go to settings, accessibility and switch VoiceOver on and you’ll find out.
2 Likes
This did come up here a few months ago, but it was not discussed extensively. Maybe @Richard.Dane can point Naim to this and someone can provide an official answer about efforts to accommodate those who are visually challenged.
Hi @IRattray, though embarrassingly long overdue, we’ve started planning our VoiceOver updates. It may not be for a couple of releases but is definitely scheduled work. If you’d like to be part of the beta testing process we’d be delighted to have you on board.
7 Likes
That’s great news.
Raised this a few months ago. I’m not reliant on a screen reader but a developer with a passion for accessibility and already on the Beta program so will help test in any way I can.
But it would be of untold value if @IRattray would consider joining too.
The app accessibility did seem to make some progress in the last major release from what I can remember.
1 Like
Oh just a friendly warning to anyone who wants to try this. It’s highly recommended to experience at least once but it turns everything that you would tap once with your finger into a double tap.
So tap to read out the text of the button (or whatever) and tap again to activate.
First time did this I had to go to my computer to Google how to turn it off again cause of this 
Hi, I’d very much like to be part of the beta testing. I’m guessing you can access my email from the forum? If not how would you like me to get in touch? Best
Ian
1 Like
Hi, yes, I should have posted a warning… If anyone tries and gets stuck drop a note on the forum and I’ll explain a little more.
1 Like
Great stuff! Please send an email to beta@naimaudio.com and we’ll get you signed up.
A quick aside: Quite rightly (and I hope you agree), I don’t have access to your email address from this forum.
1 Like
Absolutely, it’s only because I thought, as staff you may have access.
Ian
1 Like
As someone also registered as sight impaired I raised related issues. There is a tendency to assume that if you fix an app for voice over then you have “done accessibility” whereas that caters for a very small subset of visually impaired people. Something like 4% I believe last time I looked. Given the number of partially-sighted and older users with deteriorating vision there should be as much and arguably more focus on getting text sizes; contrast and layouts right.
On that basis, and having not realised it was an option, would it be possible for me to also be a beta tester or are you up to capacity?
1 Like
As administrator, only I have access to this, and used only in relation to matters relating directly to the forum and subject to Naim’s Privacy Policy.
Mike, I would recommend you also apply by email to beta@naimaudio.com expressing a wish to be a tester for App accessibility.
1 Like
Hi Richard
Just an idea, could an Access category be added to the forum? This way Naim would find out the types of issues and numbers of people who have access difficulties directly.
1 Like
If you wish to start a new thread in the Streaming Audio section, then by all means do so. But probably best to stick to this thread and see what comments come from it from other members.
I’ve just started using the app, and as a long time Voice Over user, I was pleased to find it pretty usable. I think that with some button labelling and some tweaks aiding easier navigation, it will be very accessible without any visible changes for sighted users.
For instance, I was interested to find that headings have been added to the Tidal app since I tried it a few years ago, and jumping to the various categories on a busy page is now a breeze.
It’s often just the little things that can transform the experience!
Kelvin
From what I found I agree. It was mostly a case of things being miss labelled or not findable with normal navigation.
There is a good base that, I think, improved with the last major release. Not like Roon which is completely and utterly inaccessible to keyboard and screen reader and not fixable.
The Naim app could become an accessibility standard and therefore a go to brand for folks who rely on assistive technology 
Hi Richard
I don’t think that’s the point. To have a category for Access issues would be thinking more long term. A thread if quiet for 2 months would drop out of sight…
As already pointed out earlier in this thread, it’s not just those registered as blind who use VoiceOver and would benefit from making the app more accessible. There are those who are partially sighted as well as an aging population, many of whom will develop eye conditions such as macular degeneration or cataracts that will impair their sight. I would imagine, many of your current and future clients are, and will be in that position and should therefore be considered. Therefore, having an up-front category would give people a gateway in to letting you know what access issues they’re having, which surely is a good thing? Also, having a track record of the issues faced by clients will help future developers new to Naim.
For the app developers to perhaps consider when planning accessibility improvements.
There is ‘accessibility’ where everything talks, and there is ‘usability where the things you need at that moment talk’. It’s a balance that when it’s right, it’s great.
Imagine the whole screen reading completely, from top to bottom, every time it changed. It could be argued this gave 'accessibility, but it is clearly not very usable.
Voice Over users will read and navigate a screen in a variety of ways.
By remembering the physical location of a button on the screen and putting a finger straight on it. If the Back button is always top left, it can be found immediately, and just the button is spoken aloud.
Also, by ‘swiping’ left or right, from item to item. A quite lengthy process if the screen is busy, but normally reliable, and nothing is missed. It does though mean the swiping order should ideally mirror the order of the visible screen. I have noticed on some app screens I can put my finger on the top left to find the Home button, but if I ‘swipe’ right, the Home button appears to be near the bottom of the screen.
Another way is by swiping down by the chosen increment. For example, by Heading.
Being able to jump by Headings or Containers on a lengthy page makes Voice Over very much more ‘usable’. Reading down through the Tracks a line at a time, to find the start of the Album list, can be tiring. Jumping by headings to the Album section is liberating, and presumably just needs a marker in the coding for Voice Over to use.
Kelvin
2 Likes
We have tried to keep categories/rooms to a bare minimum, otherwise you end up with a messy forum and dead rooms where nothing ever happens for weeks or even months on end.
Accessibility is an issue that concerns the App and streaming, hence most appropriate in the Streaming Audio room.
Of course, if Naim wish for a separate room for members to discuss Accessibility then it’s their forum and of course that is what they shall have…
Yeah I agree with you.
Speaking totally from outside Naim software dev team but having had plenty an accessibility discussion on other projects I worked on I guess I have a tendency to shoot for the low hanging fruit first.
So no accessibility blockers and being able to use all the functionality reasonably easily.
The situation you speak of is no doubt the most desirable but this is achieved most easily when the app is designed with accessibility in mind from the start. In this case accessibility has to be fixed in an already released program.
In my experience an all or nothing approach that may even require changing part of the application architecture significantly will cause the accessibility task to always be bumped further back in the backlog.
So I think the more we can highlight blocker problem areas and quicker wins that can be done in the current app the quicker these features will appear.
Not that the more tricky things you say should not feature, but be loose feature requests that can be addressed separately.