Hi everyone, I'm the developer of Keybuild, an app I work on in my free time for building your own keyboard. I make it a point to support tools like VoiceOver by default, but I've specifically had feedback that the app has been working well for VoiceOver users, so this week's upcoming update is focused on optimising the VoiceOver experience. I'm linking to it here in the hopes of getting some feedback on the changes, the update notes for which are included in this post. The update should hopefully make Keybuild a bit more accessible to new users, though I'm sure there's still more I could be doing.
I'm making this update available for free on Testflight until Friday (14th), at which point the release will roll out to users, and the Testflight link will stop accepting new users. Testflight builds then expire automatically after about a month and a half.
Both posts to this thread, and Testflight feedback are set to go straight to my email inbox.
Here are the links:
The Testflight link has now been disabled. Testflight link.
Here are the update notes. They include the unicode bullet point character which iOS's speak selection seems to have trouble with, reading the first as a comma and ignoring the rest. It's pretty standard for update notes to use this character, I'm surprised that's a thing. Anyway, update notes are as follows:
The VoiceOver once-over!
FEATURES
• Added a Direct Input mode option to the in-app Settings page.
• VoiceOver now announces when the active pane changes, to provide confirmation and to match the stock keyboard.
TWEAKS
• The "Toggle Editor" button has changed to "Show/Hide Editor".
• VoiceOver now announces where the editor will appear, when pressing "Show Editor".
• Custom back buttons in the editor panel now have their labels prefixed with "Back to ".
FIXES
• Enable/disable shift preview labels are now the correct way round. Sorry about that!
• Resolved a minor memory leak.
• The keyboard extension now fails safely in a few situations which should never happen.
Comments
I'm still learning, and I've…
I'm still learning, and I've just found the distinction between Direct Touch Typing and regular Touch Typing modes is not what I thought. I'll be updating the wording in the app to reflect this. I'm pretty gutted there's no simple way to recreate any kind of useful touch typing mode for VoiceOver. I really wish Apple would provide some tools to enable this, but it seems I'd have to hand-roll the entire concept of buttons. I'm sure the Direct Input mode will have some uses, but maybe this is a v1.6.1 update after all.
Initial thoughts
Hello James,
First of all thanks for paying attention to accessibility in your app. I only played with it briefly and intend to spend more time with it, but I like what I'm seeing so far. The stock keyboard for my mother tongue has the accented keys accessible after holding down a letter, except if you use VoiceOver you have to hold it for almost 5 seconds for the alternative characters to appear. Since I never liked braille screen input that much I'm seeing a great use case for key build here so that I can make those characters easier to type. Being able to also add a number row and some common punctuation is icing on the cake! ☺️
Regarding the 2 different modes of touch typing, it's interesting that Apple hasn't added a way to do this. Perhaps this is a limitation of SwiftUI, because I have seen a few third party keyboards that work with VoiceOver set to the "touch typing" option - both gBoard and Swiftkey. Neither of these supports direct touch typing though so you might be the first there. For me personally, I can see myself eventually learning to do direct touch typing on your keyboard because I can make the keys much larger, but initially and for browsing other layouts like symbols I'd prefer to start out with regular touch typing - where VOiceOver reads the key when you slide your finger over it and the key is pressed when you lift it. This would be my #1 feature request.
The other thing I noticed is a small bug with the editor announcement - if an editor is visible on-screen, every time I move anywhere VoiceOver repeats the "editor is open" announcement.
Either way keep up the great work!
i don’t understand
Hi,
I’m having a hard time with the keyboard. I’m used to exploring the keyboard, and lifting my finger when voiceover announces the letter that I want to type.
However, that’s not how this app works. You have to know where the letters are.
Could this be improved?
Built-in keyboard
I like a built-in standard keyboard on iOs.
And as for me it is no sense to pay third side developing keyboard.
Just my opinion and no more.
Cheers!
Thank you!
Thank you for all of the effort that you have clearly already put in to enhancing your keyboard for VoiceOver users. This is truly appreciated, as is your engaging with our community.
From what I've already seen with the TestFlight release, there's lots here that would add significant value and productivity to my use of iOS.
Unfortunately, however, the current lack of support for touch typing is a deal breaker for me.
As much as I wish it could be otherwise, having to switch to standard typing would mean sacrificing more than I would gain in regard to both user experience and productivity.
As has already been mentioned, other third-party keyboards have found a way to support touch typing, so I hope that you will also be able to find a solution. It might be worth reaching out to Apple's accessibility team at [email protected] to see if they can provide any guidance or pointers.
Good luck and do please keep us updated.
Touch typing
I love the concept of this app. I do wish it supported touch typing, as I've noticed that having to use Standard slows me down quite a bit. Also, when the keyboard is set to the default keyboard, is there a way to save the pane that opens? I keep having to switch back over to Qwerty every time I open an edit field.
I do agree that touch typing…
I do agree that touch typing would be a must for me as well. I know GBoard supports this and so does text expander's keyboard, both of which I use. You could get in touch with either those developers, or [email protected] as well to see what they say. Let us know.
Spoof, virtual Bluetooth support?
James, thank you for all of your work on the app! I will be purchasing this soon to support your work and will look forward to testing it once the future build hits the App Store. I know this is definitely an odd, request, and I do not expect it in this next round of updates. Is there anyway that you could have a keyboard spoof that it was a Bluetooth keyboard going back into the phone? here is my reasoning. There is an app,NVDA remote. It allows you to remote into a computer and control the computer from the iOS device. It does however, require a Bluetooth keyboard. I am going to be contacting the developer of this app to see if they can implement software keyboard support from the phone, but if they do not choose to do so, as the app only supports a Bluetooth external keyboard, it would be pretty amazing to have a keyboard on the phone that would control through a spoof or virtual Bluetooth driver. Again I know this is a lot and a bit crazy. Thanks for considering and looking into it.
Thanks everyone!
Thanks for the feedback everyone!
First of all, it's great to hear there are other third party keyboards that support touch typing. I see why not having touch typing would be a dealbreaker, and this means there's a good chance it's a system feature I can make use of. I've sent an email to [email protected] explaining my situation, so hopefully we'll find out whether it's SwiftUI that's the issue or there's just something I've missed.
Regarding Brooke's question, currently the top-most pane in the app's pane list will act as the default. You can change the default just by moving your preferred pane up to the top of the list in the standard way. I've not ever checked how reordering list items works in VoiceOver, it's something I've just trusted to work as it's system functionality. I'd assume it's an option in the rotor menu perhaps?
I'm aware this whole system of setting a default isn't very intuitive even outside of VoiceOver, I may revisit the way this works to make it easier and more obvious.
Currently, there's no feature in place for automatically restoring the last open pane when the keyboard is reopened, but it's a common request. I've got a mountain of features like this I want to add, given enough time.
Finally on Drew's point - faking a bluetooth keyboard certainly is add odd request, but I'd actually really want this too, and have looked into it before. Such an approach would open up the possibility of adding command keys to the keyboard, so one could use iOS keyboard shortcuts without the need for a hardware keyboard. However, if this is possible I couldn't find any examples or approaches online, and I wouldn't know where to start with Bluetooth drivers. Sorry!
VoiceOver announcement bug
Sorry, I missed this in my previous post.
Piotr, regarding that editor announcement bug, I'd be interested to know what device you are using, and whether this happens every time. And what mode is the editor in? As it can be a sidebar, vertical split, or fullscreen overlay. The announcement only fires once for me on an iPhone XR and on iPad. My first thought is this might be an issue with the overlay mode on small phones.
It is expected that the announcement tries to repeat itself if it gets cut off early, this was an aspect of how I was able to get the announcement working in the first place, but I can look into my options for limiting the number of times it will try to repeat if that's the issue.
Re: editor announcement
It's an iPhone SE 2020 on iOS 15.4 beta, so you may be onto something. The editors were appearing vertically, I was just bringing up various stacks.
Now that you explained it was trying to finish speaking the announcement, if I wait for it to finish it does stop repeating. But if I hear it for the second or third time I got used to where the editor is, so I just touched where the editor appeared and started navigating around. THis is where it would endlessly repeat itself, so it's a good idea to limit this to only a handful of announcements.
Thank you
Thank you James for your kind response.
Quick update
Hi all, I've not had so much time this week so I'm only just getting to a reupload with the corrections. I'll still be aiming for release on Friday. Sadly no response back from Apple yet, so I'll be deferring touch typing to a later release if I can get it working.
Question on VoiceOver hints
Update: I've had quite a few answers in the other thread on this. I'm going to consider the option/gesture for additional VoiceOver hints as kind of a tutorial mode. For specific cases like the sidebar appearing, I'll keep the one-time announcement, and in the general case, just try to design in such a way that it's reasonably obvious what to expect without the hints.
Original message:
I've been going backwards and forwards on this, so I'm putting the question out there.
I've implemented the change to make VoiceOver read the announcement as to where the editor appears only once per device. I think this is the best approach, but I've been really wondering whether this might have made more sense as an accessibility hint?
As I understand it, there's an option to enable a gesture to read the hint when invoked. If true, this is great for this example, in that it would become opt-in to get this additional information, and it wouldn't bother users familiar with the app if it were added in an update. However, the only topic on the forums here, when searching for the term "hints", is asking how to turn them off, and implies they're read every time.
I've opened a separate topic on accessibility hints too, around whether people use them in general. But I also want to ask specifically around my app's particular use-case, as on a big tablet screen where the editor opens in a sidebar, the editor position might be considered "important information" that you wouldn't want to hide behind an opt-in feature. Hope this makes sense.
Touch typing issue
Hey James,
This si such a cool app. You don't know how long I've been searching for a virtual keyboard with number keys at the top. Anyway, I've been Googling the issue of Voiceover and touch-typing and it seems there's a guy who was working for Voiceover support liek 4 years ago and he had gotten touch typing to work. Anyway, this thread is about the delete key, but he does mention touch typing. You might want to reach out to him and see what he says.
https://developer.apple.com/forums/thread/76508
Cheers,
Martoin