Please sign my petition, Apple, commit to never again wilfully excluding disabled people from public betas

Accessibility Advocacy

Hi fellow AppleVis members.

Today I did something online I've never done before. I set up an online petition, which is available at . I'm under no illusion. I realise these things don't usually change the world. At the same time, I think the precedent Apple has set with its recent deliberate exclusion of blind people in the watchOS public beta is alarming and that we should stand up and be counted on this. I appreciate that people feel strongly on both sides of this issue, but I hope you will consider the reasons why I think it is necessary that we respectfully express our concern about this. If you agree, please share the petition, and sign it yourself.

When encouraging developers to make their apps accessible, Apple puts it simply. "It's the right thing". And so it is.

As everyone reading this knows from our daily experience, Apple's commitment to accessibility has transformed lives. Each year sees more innovation which results in increased opportunity for disabled people.

However, where VoiceOver, the screen reader built into Apple products is concerned, in recent years serious quality control issues have created difficulty and frustration every time Apple issues a major operating system update. The amazing innovations keep coming from Apple every year and I am very grateful for that, but the quality control issues really are a problem that can affect our productivity, independence and even safety.

It is therefore critical that we can offer constructive feedback when it can make a difference. The earlier we can get our comments in, the higher the chances of there being time for Apple to fix bugs.

Sure, we love being on the cutting edge and trying the latest and greatest, but there is an element of service about beta testing too. We volunteer our time and take the risks inherent in testing beta software because we care and want to make Apple products better for the good of all.

When Apple released watchOS developer beta 4 without VoiceOver working, some people said it wasn’t so bad because it was only a developer beta, so they reluctantly accepted it. Despite a week having gone by when such an impactful bug could have been fixed, the first ever watchOS public beta was released without the ability for blind people to participate.

The implications of this are that any Apple Watch owner can give Apple feedback on watchOS 7, except blind people.

The more time that goes by, the less likely it is that any significant bugs can be fixed before release.

People point out that beta software has bugs, that’s why it’s beta. And of course, that’s true. Beta testing is a jungle out there dude. Things break, and sometimes they break very badly. But it’s a bit more nuanced than that. I’ve been a senior product manager at two IT companies. I know that sometimes a beta build is produced, and it goes to the quality assurance department for testing. If a bug is found that is so severe that it is considered a showstopper, the developers must fix the bug and a new build is spun and sent back to quality assurance for more testing. So, what kind of bugs are impactful like that in the context of the Apple Watch? If a software update broke the digital crown or rendered the touch screen unable to get input or output, that build would never leave Cupertino because it would break people’s devices.

So, there is clearly a list of things that make a software build too bad to release. I contend that VoiceOver not working at all should be in that category. If VoiceOver can’t function at all, you effectively brick the device for blind people and exclude them. It should be considered a build that fails the eligibility criteria for going out to beta. There may be all kinds of issues, VoiceOver may be rough and ready, but to knowingly release a build that renders the feature completely inoperable is in my view a step too far. It sends the signal that our bug reports aren’t important enough.

Because of the quality issues blind people have experienced with Apple in recent years, to many this feels like yet another slide down a slippery slope.

I respectfully urge Apple never again to release a beta build when they know it renders a device totally inaccessible to any group of disabled people. It undermines confidence and tarnishes Apple's brand.

An unequivocal, public commitment from Apple's Chief Executive on this matter will help restore confidence in the quality of Apple software. Ensuring we can all participate in building better products is a win for us and a win for Apple. 

Thanks for reading, and I would be grateful for you signing and sharing.

And for those of you missing your Apple Watch, perhaps because you didn’t turn automatic updates off so you got updated to developer beta 4, don’t forget there’s a song by Chicago from the 1970s called “does anybody really know what time it is”. It’s on Apple Music.



Submitted by Alan on Friday, August 14, 2020

I can't agree. There is a feeling floating around, something that, in my opinion, is growing like an urban legend. The premise is: recently, Apple's accessibility is getting worse. And in my experience it's not true at all. It seems to me that some users don't remember what happened with older ios versions, or they never tested beta versions.
That said, from my point of view, a lot of users think installing a public beta is just the fastest way to the next ios version, and it is not. Sometimes developers cannot stop the complex betatesting process because of a feature. We must assume that voiceover is a feature' not a priority" Perhaps it should be a priority, but some users have no complains against the accessibility of their cities, their goverments services, their new microwave or whatever, while every new ios release seems to be the end of the civilization.
It's only a bug that will be fixed, possibly in one or two weeks, don't waste all your energy fighting the wind. The paradox here is as follows: the more a company works on the accessibility of their products, the more complains from the users because it's not perfect. However, companies that simply ignore accessibility seem to be free of complains, campains and groups of people standing up for their rights.
Just my opinion, respectfully.

Submitted by Joe on Friday, August 14, 2020

Club AppleVis Member

I would care about this if we treated mainstream companies like Apple and Google the same as VFO, Humanware, and others. Quite frankly these companies that quote make things for the blind give us something then never really fix major bugs with the software. Yet we don't stomp our feet and act like children. I'm not saying that's what your doing here, but reflecting on what I normally see here on this forum. I use a Braille Note Touch plus I can make it freeze where the only way to fix it is to pull the battery I've reported this for years, because it was also reproducible on the touch and HW hasn't fixed it. I don't like being excluded from things, but at the same time they did put out a warning and let us know. I think there are far more challenges for me to get involved with this just isn't one of them.

Submitted by Holger Fiallo on Friday, August 14, 2020

Will do so. Unlike some people here, I do believe that Apple did not consider those blind people who are doing beta testing. They do not get it and will not.

Submitted by That Blind Canuck on Friday, August 14, 2020

Thanks Jonathan for this, I got your email message yesterday and have already signed your petition.

I fully agree with you and Holger, that although VoiceOver is considered by many a feature, in my mind it's a crucial feature to many blind users.

For Apple to willingly release a Developer and Public Beta that completely breaks VoiceOver and prevents blind users from providing critical feedback to Apple in order to improve the experience for all blind users was, in my book, completely unacceptable.

Submitted by Paul Martin on Friday, August 14, 2020

It seems to me we forget history, and also how much better this was handled than the status sell incident of iOS 8 mentioned in this here fine post, noting of course that was a public release all those years ago. Let's be thankful we're a month or 2 away from the official release of this software, as dictated by history. Also, the issue was noted quite clearly, even before the public build was out, and could be found quite easily in the feedback assistant without the need for this being posted here and causing a bigger commotion than it's worth. The apple accessibility team has pulled through bigger messes in the past, so i'm sure this nasty little bug will get the hammer of bug smashing in at most a couple weeks.

Submitted by Ekaj on Friday, August 14, 2020

Thanks for this Jonathan. I posted an entry over at my journal last night about this. I think the entry is pretty self-explanatory, but I will reiterate that I was rather surprised to see this. Here's hoping the issue will be rectified very soon. P.S. That is a good song indeed.

Submitted by Soupy on Friday, August 14, 2020

Yes, it sucks that VoiceOver is broken in this beta release.

We will never know the specifics of what caused VoiceOver to be broken. But, unless you think that Apple did it on purpose because they hate blind people, the most likely explanation is that an unintended/unexpected consequence of a code change was to either break VoiceOver support or introduce issues that made it practical or necessary to disable VoiceOver support for this release.

If this is indeed the case, what would we reasonably expect them to do?

Option one is to do what they did - issue the release as planned, but with a warning to VoiceOver users.

The only other option I see would be to simply not issue another beta release until VoiceOver is working again.

Who does the latter benefit? It doesn't benefit me, as the more beta releases in the hands of testers, the better the finished and complete software should be.

So, those of you criticizing Apple for issuing this release, what do you think they should have done when faced with broken VoiceOver support and are working to a deadline to get watchOS 7 released?

As I said right at the start, this doesn't mean that I am happy with broken VoiceOver support, I just don't know what people expect from Apple based upon the likely reason for it, the fact that it's a beta release, and the reality that Apple is working to a deadline.

I'm not sure to be pleased or not to be reminded of that first iOS 8 release, as I had forgotten just how buggy it was and just how nasty some of those bugs were.

It should certainly be an eye opener to those around here who think that the accessibility of Apple software has got worse and that Apple cares less now than it used to.

But, I will accept that it probably also demonstrates that the introduction of public previews has been a big factor in ensuring that more bugs are identified and resolved during the beta cycle, so VoiceOver users losing a couple weeks of a beta cycle isn't welcome.

First, the fact that it is a beta means you should expect bugs, known issues that still need fixing, etc. Some are minor; some are not. But look. Go to this link.…

Right under Accessibility it says:
Known Issues
VoiceOver isn’t functional in watchOS 7 beta 4. If you rely on VoiceOver, don’t update to watchOS 7 beta until this issue is resolved. Enabling VoiceOver
in watchOS 7 beta 4 might also cause a significant battery impact. (66475455)

How could they make that more clear? they are already aware of the issue. And sorry, but we are not Apple's only priority. How many other companies don't even include notes on accessibility or screen readers in their release notes?

If you read that and then go ahead and install the beta on your primary device, that's entirely on you!

Submitted by tirablue on Friday, August 14, 2020

For days I have seen tweets saying "Do not install the latest watch OS because it breaks voiceover." "Voiceover is broken in the latest watch OS do not install!" You are a well connected individual who should know better than to install the update. This petition is a waste of Apple's time.

Submitted by Joseph on Friday, August 14, 2020

I don't much like the petition either. As has been said here multiple times, Apple did, in fact, issue a warning to VoiceOver users to *not* update to this beta, and that if they went ahead and took the plunge anyway and still enabled VoiceOver, there might be a massive hit on battery life. You are a well-connected accessibility advocate and should definitely know better than to post a petition like this. Seriously man, do better next time around.

You have the tools, the training, the voice, and the knowledge needed to make accessibility become a more wide-spread thing. Petitions like this don't do any favors for anyone in the long-run. And we wonder why a lot of companies tend to look at us as ungreatful or whiny. I will certainly not be signing this, nor will I be installing any of the public betas on any of my devices. I can wait until the software is formally released to the public to install it.

Submitted by Rixon Smith on Friday, August 14, 2020

I feel that this is really a one-sided petition. When high sierra broke VoiceOver on the Macintosh computer there was not much the people ever did about complaining to Apple about accessibility and how voiceover works. I will sign the petition if it is changed to include how voiceover works on the Mac and the iPhone otherwise no one should sign this petition.

Submitted by Jonathan Mosen on Friday, August 14, 2020

Thanks to all who have signed so quickly, We have 159 signatures already and growing fast.

We'll also be discussing this at length on this weekend's episode of the Mosen At large podcast, some great contributions already coming in for that. Much appreciated.

Hi Rixon, I'm not a Mac user myself, but if there have been public betas of MacOS that has disabled VoiceOver deliberately, then I'll gladly modify the petition to reflect this. I would need the details though.

I've been testing VoiceOver for iOS long before public betas were a thing, and apart from one build where VoiceOver was broken accidentally, I don't recall iOS ever having had a build where there was a deliberate release that did so.

If you're talking about quality control issues with release builds, then I know it's frustrating but I think anyone who wants to should set up a separate petition on that. This is specifically about our ability to participate in the beta process at a time where our findings can make a difference.

Submitted by burak on Friday, August 14, 2020

Deliberate exclusion? I don't think what they have done can be called that. Perhaps something very important was wrong with voiceover, so instead of keeping voiceover with that extreme wrongness, they prefered to get voiceover out of the system to fix it. I'm sure they will put it back in the next time. You don't want such brokenness? Don't test the betas.

Submitted by Tech_Enthusiast on Friday, August 14, 2020

there isn’t anything I can add to this which hasn’t already been eloquently stated, however, I do want to lend my voice in ascension to those who are apposed to this petition. As has already been pointed out, Apple made it very clear that voiceover will not work with watchOS beta 4 for developers, or public beta 1. Alternative for this is simply to uninstall the beta profile from your watch app, wait for the next release, which will undoubtedly bring us a fix, and get on with the business of living. With betas come broken pieces and parts for everyone, hence the nature of beta testing. Does it suck, of course it does, but I’m one of those who just uninstalled the profile, and still have VO running smoothly on my watch. This is a good thing, because I need it for a rowing challenge which is due to continue tomorrow.

As for the petition itself, and the seeming motivation behind it, had Apple not warned us about the existence of this voiceover conflict, we’d have every right to be upset, however, the message has been in the beta release notes since beta 4 Dev version first went live. As far as I’m concerned, and thankfully those of you who also think and acknowledge the reality of a situation before tossing out such knee-jerk reactions, that’s all they could have, and should have done to prevent unintentional installations by VO users.

Lastly, in response to Jonathan being an accessibility advocate, and one of this community’s figureheads with regard to technology, if this type of response to an issue Apple has already acknowledged *is an issue and will doubtless provide us a fix for in a few days, I for one cannot say I am happy about owning this method of so-called leadership as it relates to what the blind community represents for me. Again, thank you to those of you who wrote well-considered responses to this issue, and who can see reason and obviousness amid all the me too responses.

Submitted by Scottsdale on Friday, August 14, 2020

If the petition was proposing a rational, logical argument, something along the lines of "Apple would delay the release of a beta if the screen wasn't working, ergo, we're requesting that in future, issues that prevent Apple's screen reader from running be treated with the same priority", I'd have signed. Instead, I'm being asked to sign another petition that's choc full of unnecessarily divisive language (the word "willfully" in the title to take perhaps the most egregious example), and I'm not willing to do that. I'm tired of divisive language representing me by proxy. If you want this to achieve anything, I'd strongly urge you to consider a rewrite. Good advocacy isn't only about the number of signatures you can muster.

Submitted by Nikola Jovic on Friday, August 14, 2020

So if I may ask, since you created the patition, it means that apparently Apple is not listening to us or treating us equally and you want this to change. So your opinion is that 100 to 500 signatures will be enough to change Apple's way of thinking? You do realize that this number means absolutely nothing to Apple? In fact, I would say they get 100 hate mails every day that have to be dismissed. Now, I would like to write some more about the entire situation. When you are beta testing, you are signing up for a build that is potentially completely broken and unusable. You are saying that if this was an issue for sighted users, this would be fixed and the beta would not be released, which is 100 percent factually incorrect. Would you like a proof of this? Here it goes...…
if you read this one carefully, you will notice that this bug affected the stable release of iOS 13.2, not a public beta, not a developer beta, a stable release. The update completely broke home pod for some users, which is a very, very serious issue. So I would ask you to please never mention that Apple is doing this intentionally again. Apple has made the watch accessible from day 1, you literally had Voiceover support in the first generation, while most other competitors bring completely inaccessible watches, or accessible but with major issues and inconveniences. So you are trying to tell me that we should petition Apple for breaking a beta release, yet be fine with products which are completely inaccessible? Can you name 5 brands of smart watches that can be used completely independently without any sighted help that are not Apple? I know I can't.
Now, let's focus on the bug itself and Voiceover being broken in the current beta of Watch OS. How many blind people use a watch? Do you know what is the total percentage of blind watch users for Apple? Now, out of all those people who do use a watch, are all of them beta testers? I would say no, in fact that percentage is even lower. So you are telling me that Apple should not release a beta until a bug is fixed that affects 1 percent of users, if even that? By that logic, Apple should never release a single beta, because almost every beta will be unusable for somebody. I'm sorry, but how beta testing works is that bugs affecting larger groups are prioritized, this has nothing to do with Apple, it's how Microsoft, Google, how everybody does it. Even then, bugs slip through, unusable betas are released for literally everybody. There was an iOS 13 beta that literally bricked IPads, and I didn't see petitions about that. It makes me very sad to see such a petition. Apple is giving us so much, yet we always cry and want more and are never happy. Instead of spending your time on this, I wish you spent the time to petition Google and make their Wear platform (the Android smart watches) a lot more accessible then what they are now, because that is when I feel excluded. I feel excluded when I hear that Talkback is on them still an experimental feature and works well only on a few models, not when I cannot use a public beta release. I understand your arguments that the time for reporting bugs is limited and that we should have the right to do the same, but this argument works both ways. So if let's say Apple avoided releasing this beta because of Voiceover, 100 percent of watch users would not be able to report a single potential new bug. I'm sorry, but if I was Apple, 99 percent of beta testers being able to report bugs is certainly more important than excluding all that and focusing on the 1 percent of blind users. This feels extremely ungrateful and unreasonable to me, and I am very surprised to see a petition about pre release software. Again, whenever you think Apple is deliberately doing this, just go ahead and tell me what other smart watches can successfully be used. Apple could have also went with the logic of oh well, watches are not so common amongst blind people, nobody else seems to focus too much on the accessibility, so maybe we could release Voiceover a little later, but no, they did it right away. Thankfully, somebody else already pointed out the tone and the language used in this petition, and I felt it necessary only to point that the same can very well and has already happened in betas for sighted users.
With that, I look forward to the release of next beta, which is most likely going to be in a matter of weeks, and about which I am 100 percent sure the bug will be gone. Not because of the petition however, but because Apple is probably very well aware and is working hard to resolve it. All we are doing is making their job even harder by sending complaints about a bug they already know and wasting the time of everybody who has to deal with our bug reports.

Submitted by Rob on Friday, August 14, 2020

I think some folks are missing the point here. Regardless if Apple issued a warning to not update to the public beta they were aware of this issue during the developer release. Would we want Apple to release an official build of IOS knowing that Voice Over would not work? Would a warning advising Voice Over users not to update be acceptable simply because it would not coincide with a release timeline? The bottom line is that Apple would not release a developer beta or public beta if doing so meant that general users could not see their displays. Warning or no warning the message this sends is that Voice Over users are expected to take a back seat. Obviously, I know that this is not how Apple feels about equality but we are not guaranteed that this issue will be fixed during the next developer or public beta release. We should praise Apple when it is warranted and we should take them to task when it is warranted as well.

Submitted by Brad on Friday, August 14, 2020

We have been warned not to update so I won't be signing this.

Apple didn't leave us out, in fact;they included us by writing what they did.

As for Rob asking if i'd be ok with apple saying don't install the latest version of IOS because voiceover doesn't work on it, I would. I might want the latest features but at least I'd be warned and then if I do the stupid thing and install it, that's on me.

Submitted by Carlos Taylor on Friday, August 14, 2020

Last I knew, this public beta cycle is optional. There was a warning from Apple that VoiceOver is problematic and not to install the beta if you rely on Voiceover. Therefore, your device is still usable if you don't install this particular beta. VoiceOver is software built into the operating system. When there is a beta cycle of the entire operating system, every part of that operating system is considered to be in beta, including VoiceOver. There will be bugs during a beta cycle. To say it is acceptable for certain bugs to exist while others shouldn't exist doesn't make logical sense to me. After all, that's why it is called a beta. If VoiceOver itself was flawless, bugs elsewhere in the OS could cause unexpected and undesired issues to occur with VoiceOver. Such undesired side affects could potentially cause VoiceOver to be unusable, even though the problem might entirely lay elsewhere. Should other accessibility features in the OS be excluded from bugs during beta cycles too? This seems completely unrealistic to expect certain parts of beta software to be bug free while thinking it is reasonable too expect bugs from other areas.

Submitted by DarkWingsRaven on Friday, August 14, 2020

So I normally don't comment on here, but reading through all of these comments has compelled me to give my two cents on this.
I think this petition is absolutely valid. Apple, as awesome as they are (and I promise that is a genuine observation from me, not mocking) are not above reproach. Just because they are, in many respects, a leader in accessible mainstream technology doesn't mean they're faultless or get it right every time. The fact is: Voiceover users took a back seat. We were seen as less important than getting the beta out there on their timeline. And yeah, it was great that they warned us; that's more than other companies would do, but that should have never had to happen in the first place.
The issue is, so many of us see accessibility as a feature, a perk, or something a company provides out of the kindness of their hearts. That's not true. Accessibility is a right. It's not a privilege; it's not a charity service, and it's not something we should have to beg for. Like many have pointed out, if this beta broke the touch screen interface for sighted users, it would have never seen the light of day until this was fixed. Look at the bigger picture. Sure, it's not a big deal to some now. But will that change when the official release comes out and there are a hundred accessibility bugs that could have been found and squashed in the beta if it had been accessible? The change starts with us, truly. When we stop seeing our access needs as subject to the whims of the non-disabled, the more power we will have.

Submitted by Igna Triay on Friday, August 14, 2020

While I'm seeing both sides, I against the petition myself. Look, if apple wanted to make this disabling of voiceover deliberate? The only thing they would have needed to do, iis not put on the notes that voiceover was broken on watch os 7.4. As simple as that. I'm guessing the voiceover breaking was a bug or something. One thing is forsure though; this was accidental. If it was deliberate, the same thing would have happened on mac os and ios betas, and, to top it off, they wouldn't fix it; if they did it deliberately. The evidence that apple warned; and clearly warned; I might add; about voiceover beeing broken on watct os 7.4, and the fact that they will fix it; state against this beeing deliberate, although yes, it sucks that voiceover has taken a backseat, and that most people have the misconception that accessibility is a feature. However this petition... I really get the why it was made, but I believe there are better ways to handle this and claiming that apple is excluding users. What i'm going towards is, the breaking of voiceover was not deliberate. The fact apple released the beta even with this... I'm trying to be neutral on this. I see why some think this was deliberate, that they knew and still chose to release it, however the argument that there could've been a major problem and they had to resort to disabling voiceover in order to fix it, is also just as valid. The truth is, we'll never know why apple went ahead and released said beta with voiceover beeing broken. Nntil the reason is known though, all this is speculation. Who knows, maybee the ones saying this release was deliberate are right; maybee not; but until we know more, jumping to one extreme or the other... is kind of rash without having more information.

Thanks very much for your feedback on the petition. You clearly do understand its fundamental point, so I'd like to address the concern you've raised.

In this case the word "wilfully" is not divisive, it deliberately narrows the scope of the petition.

Sometimes, bugs will slip through even the best QA testing. There have been a couple of Apple release builds where this has occurred, the HomePod one being the most recent example. The famous iOS build that broke cellular connectivity is another. Asking Apple to never again release a build that breaks VoiceOver isn't realistic.

In this case though, we have a build that has been released to two different streams where Apple knew VoiceOver didn't work. We know this because they put it in the release notes. Betas are called betas for a reason, so we take the risk when we participate that something may be broken. Sometimes those things are broken by accident, sometimes they make a call and release deliberately when they know something's broken. The key here is to make the point that if Apple knows the beta will render a group of disabled people unable to participate, their QA processes need to define that as a critical bug making the build unsuitable for external use.

I appreciate the interest and the feedback.

Submitted by Holger Fiallo on Friday, August 14, 2020

How those developers who release beta of apps can continue to make accessibility for apps such as Weather Gods to be accessible? This mean that WG will have to wait until next week Cross finger for the next release of OS with VO to continue to make sure that the app will work well for the watch along with the phone. I know those who were doing beta are not able to contribute to any beta program of apps that they sign for it until VO is added again in the beta 5. They lose 2 weeks of making sure their apps are accessible. Think about it. So if Bella the cat has an app and was tested in OS 7, bugs will not be address ASAP. So those who may cry about the app not working well, think Bella the cat lost 2 weeks to address this. Lucky all of you she is not interested in developing apps.

Submitted by Nikola Jovic on Friday, August 14, 2020

2 weeks means nothing for app developers for one simple reason, they test their apps with each new beta and make sure it works as advertised, or at least that is something they are supposed to do. That is the reason it is called a "developer" beta. Even more importantly however, it happens very, very rarely that a developer needs to modify their app so it is accessible in the next beta. If an app follows accessibility standards, it will most likely remain accessible without any issues, so I am afraid this is a non issue.

Submitted by Holger Fiallo on Saturday, August 15, 2020

In reply to by Nikola Jovic

Hope a developer respond to see if you are right. I am not and Bella the cat is not interested in it. She mostly do not care for people. I think she may be right specially when they are not logical.

Submitted by mario_hardrock on Saturday, August 15, 2020

hi Jonathan, I'm with you.
I already signed.
this should have been done a few years ago.
but patience has limits.
and limits demand rights ...
thanks for the courage good friend.
God bless you.

Submitted by Tyler on Saturday, August 15, 2020

Member of the AppleVis Editorial Team

In reply to by Nikola Jovic

When it comes to wide spread issues in general releases, such as updates bricking devices or breaking key features, the large number of users experiencing the problems means that Apple will hear about it very quickly. Apple's social media accounts and support lines would be bombarded with complaints from users, and tech media would report extensively on the blunder.

When it comes to an accessibility feature broken in a beta build, however, legitimate questions and criticisms from a comparatively small number of users may go largely unanswered and as a result, similar bugs could occur in the future with accessibility possibly becoming gradually under-prioritized in the beta process.

Personally, while I don't know what is behind VoiceOver not working in this build, nor can I speak to Apple's intensions, I do have a sense of what the impact of this issue is, that VoiceOver is nonfunctional and thus people who rely on the feature the same way one might rely on a touch screen miss two weeks of testing as the public release draws closer. Going forward, I am concerned what precedent this could set, especially if no watchOS testers had called them out. With smaller numbers, I've always wondered if people in such use cases should be more vocal so that their concerns don't get lost in all the other reports filed by people actually able to test the beta in the amount of time that they couldn't.

Submitted by Khushi on Saturday, August 15, 2020

I've started using an IPhone just over an year ago. still, I feel the following with due respect to everyone.
in my opinion, voice over or any other accessibility feature is not just a feature. it is what allows blind and other disabled people use a Tec independently.
if voice over was not working, why release the public or developer beta? this just proves we've a long, very long way to go before accessibility is mainstream. apple did not mention any accessibility feature in WWDC 2020 as well. why? probably they think it'll be too boring. accessibility isn't yet mainstream and we should change this.
I have never signed any petition before, but I will sign this one. just because I want to live in a world where accessibility is not an afterthought but something which is mainstream.
again, disclaimer, these are my own opinions and I do not want to disrespect anyone.
in fact, I don't even know why I posted this comment but I am doing it hope that's okay :)

Thanks for the reply, Jonathan.

I think I understand a bit more about your intent now. I agree with the point you're raising in principal, and although I think it's unlikely to be wholly adopted by Apple because there's an inherent incompatibility with the scale that they're operating on, I'm with you in as much as it is a point worth raising, and I've emailed their accessibility team to raise the same point in my own words.

All that said, I can't agree with many of the linguistic choices you've made in expressing your version of the point, and TBRH, I'm still irritated that the petition represents me by proxy. From here, it simply doesn't seem like language verging on militant is needed to express the point we've both raised.

When I posted yesterday, my only evidence for that was a gut hunch based on advocacy in my field. Since then, I've received a reply from Apple's accessibility team with responses in line. To me, their reply indicates that productive dialogue is possible on this topic without leaning so hard into what I'd consider to be overly dramatic language.

But hey, broadly speaking, we agree it could've been handled better. Fingers crossed that next time, it will be.

Submitted by Oliver Kennett on Saturday, August 15, 2020

What confuses me is that there is internal testing, developer testing and then public testing. Apple should do its utmost to include all users in the beta. There were multiple opportunities to fix the bug before pushing it out. This is an irritant to me, however, it is beta software and apple has absolutely no obligation to make it accessible. What is often argued on here is president, apple has been good in the past so should be good now, the important word there being 'should', a word that is problmatic.

Simple fact is, Jobs always pushed for perfection, Cook is looking for bottom line.

Submitted by a king in the north on Saturday, August 15, 2020

In reply to by Oliver Kennett

internal testing won't help you fix bugs if you have set development cycles with deadlines. In software as complex as an operating system, its impossible to ship a "perfect" beta, if there is such a thing. Betas may (and have) broken devices to the point where they are unable to boot. They may (and have) dropped promised features from public releases. This is inevitable.

Submitted by a king in the north on Saturday, August 15, 2020

As a blind beta tester who has been testing beta software (both public and development betas) for years, this reaction from the community is simply absurd, and its clear to me some have zero experience with this.

I've had macs and iOS devices completely crash on me during beta releases. But you know what? I don't go and complain about how VoiceOver constantly crashes on web pages, or how it sometimes has serious performance issues. I developed my own process for beta testing instead. I keep weekly backups of my devices, download the necessary files to downgrade in case something goes wrong with my devices. I chose to take a risk, and ultimately, I am responsible for what happens to my devices, so I keep myself safe, which is what most should be doing anyway.

Submitted by Jonathan Mosen on Sunday, August 16, 2020

Hi everyone, thanks very much to those who have signed this petition and continue to share its important message. Knowing how much it can take for people to put their name to an online petition, I could count on one hand the number of times I've signed one myself for example, reaching this milestone in a small online community like the blind community is a great start.

For those who would like to hear a more detailed discussion about the motivation for and importance of this petition along with some listener perspectives from the community, it's the first discussion point in the latest Mosen At Large Podcast. As well as being available through the link above, you can hear it on Apple Podcasts and anywhere else you get your podcasts.

Thanks again.

Submitted by Marro on Sunday, August 16, 2020

In reply to by a king in the north

This behaviour is indeed very absurd and makes us look like spoiled brats who expect everything to work how they want without bugs. It is called a beta for a reason and not everything works and stuff will break. Also this is the exact reason why people who try their best to get accessibility done in certain companies don't get on here as frequent as they used to be, and some even got driven away from these kind of forums. I think we should all wake up and rethink this whole situation as it is beyond me.

Submitted by KE7ZUM on Monday, August 17, 2020

I agree. A petition like this in my humble opinion is not necessary. Apple have fixed seveal accessibility bugs I've reported in fact i see the now in the release notes especially if there is an issue and they know it. I believe this petition will, in fact, fail.

Submitted by Kayaker on Tuesday, August 18, 2020

This petition should not be supported. It misses the purpose of public beta programs. And, I would argue, makes our community look ignorant and uneducated. There are better places to focus our attention.

Public betas have two main purposes, one marketing and one engineering. The marketing one is to get people excited. I won’t comment on that because I am an engineer who has real world experience with dozens of major time critical cyclical product releases. Engineers want to get feedback on new features. That’s why we do public betas. It’s not to make the end users feel good. And what the petition author fails to realize is that in order to get that feedback, it’s often more important to release working new features sooner so that feedback on those new features can come in as soon as possible. This behavior is not a slight on voiceover users, but simply a desire to get data on the newest features in time that it can be acted upon to make a better final product.

Apple’s operating systems are date-driven releases, there is no such thing as a stop ship bug. Features will be cut if they are not ready in time because new hardware demands the new software be ready. We have seen this many times in the past iOS releases as announced features aren’t made available in the initial release, but are added in point releases later.

I would also like to point out that the public betas are always the prior dev release. There was no additional work made in the week between the dev and public beta releases. A better test is what does the next dev release look like and has it advanced? But even then, what ultimately matters is the final release.

It all boils down to this basic game theory of two options:
Option 1. Release a beta without all parts working to get early feedback on feature complete parts and be able to iterate on that feedback.
Option 2: Wait until it’s totally working before releasing a beta even though parts are already feature complete.
How does the game end depending on what option you chose?
If you chose option 1 you get more time to squash problems on feature complete units thus making your final release more stable. If you chose option 2, you lose time and risk an inferior final release that could have been better had you only the time to address feedback that came in.

The only logical choice is to pick the option that gives you the best final release. Unfortunately this time it meant VO was not supported. I’ll take that every time if I get a better final product, and you should too.

That said, there are many areas where we should pressure Apple. Two come to mind. First, I would focus energy on getting Apple to fix the backlog of VO bugs across the board and make that a priority. If the mouse or keyboard or display had as many glitches as we deal with using VO, Apple would have been out of business long ago. Let’s keep an ear on the ball and concentrate on what truly will make a difference to the final release. Second, get Apple to reject any apps that don’t pass basic accessibility tests that are available in Xcode. That alone would assure we never hear the dreaded button button button label as we flick through the UI. Now that would be worth a petition.

Thanks for your time.

Submitted by Siobhan on Wednesday, August 19, 2020

Who's to say this wasn't already coming out? I don't believe a petition online, even so many has supposedly signed, was the force behind this. Petitions are becoming like those old school forwarded emails you'd see. Send this to ten people and good things will happen, you'll make out with the person who you've had a wicked thing for forever... It's fixed. Next topic?

Hi everyone and thanks for all the interesting discussion. It is always good to have a respectful exchange of views.

Just to be clear, the petition has absolutely nothing to do with VO working again in watchOS developer beta 5, which should be public beta 2. I would have been very surprised if they had gone another build with VO not fixed.

The issue here, and the point of the petition, is whether intentionally releasing a build knowing full well that it renders the product useless for a group of disabled people is OK.

That's not to say the product will be bug free because no software is, let alone beta software. If you run the betas, you're obviously keen to look for and report bugs.

It's also not to say that one day a build may be released that doesn't break VO by accident. Stuff happens.

So the petition has a very clear message. If Apple knows they are going to break the product entirely for a group of disabled users, they should consider that a show stopper. In my view we should have as much time as possible to report bugs, and if we're not testing because the build is inaccessible, we're not reporting bugs.

We're just under a thousand signatures now, which is a great effort so thanks to all who've stood up for this important principle. Blind people's feedback is important too. We should have the opportunity to feed back at a point where it can make a material difference to the final release.

Submitted by Joe on Wednesday, August 19, 2020

Club AppleVis Member

So the only question I would ask you Jonathan is why not have a petition for the Samsung watch which in its final release not all apps are supported by voice assistant? maybe it’s a simple as you don’t use that platform but that infuriates me much more than what Apple did with beta software. That’s why I think this is misguided.

Hi Joe, obviously I don't want to go into the weeds on this one too much as it's off topic for AppleVis. For my mobile use, I am deeply entrenched in the Apple ecosystem and don't see that changing, so these issues affect me personally and that's why I started this petition.

But anyone can start a petition for free and let people know, so that others who feel similarly can sign.

Prior to this one I have not set up one before and I don't think it is something I can see myself doing often.

People are not getting the point of this. They will not. Makes you wander about their ability to understand what Jonathan is saying. Bella the cats is not surprise. She thinks people are not that able to understand. Well is a free nation.

Submitted by jay on Thursday, August 20, 2020

I sent your petition, and I do agree that Apple needs to be aware of these issues. They need to test the software internally before releasing a public beta to the public

Submitted by Matthew on Thursday, August 20, 2020

Hello Jonathan,
I am most definitely not signing your petition. It is clear to me that while you may have worked in quality control, you have little to no first hand experience with software development. While at first this bug may seem rather serious, because you're taking things a bit personally; it's really important to realize that while developing software, especially software that sells money is what's coming first. Like it or not, we're a fairly small percentage of the population. Those of us with apple watches? Yet a smaller percentage. THose of use with apple watches who install beta software? We're at such a small piece of the pie now it isn't even worth counting. If as you keep coming back to, the screen or crown stopped working? That prevents a lot more people than us from using the thing,. They gave us a warning, and it's already being fixed in the next beta, and this is honestly already more than I'd expect from most companies. Yes, we were prevented from installing one beta by a bug, nobody forced anybody to do so however and the fact that it wouldn't work was made very well known. If this had started becoming a trend, I could definitely think differently. It didn't though, so it really seems like you're choosing a kind of odd place to stand your ground. I'm ashamed that the world listens to you, and that you represent our community. Thanks for proving everybody right.

Submitted by Mathieu on Thursday, August 20, 2020

I do not understand the purpose of this petition. You know that a beta should not be installed on a product that is used daily.
This is a bug that will be fixed. The beta is not used to brag about having the latest system, but to fix bugs, on a product used only for that!

Useless petition in my opinion, create petitions against other companies that need it more!

Submitted by Kayaker on Thursday, August 20, 2020

I guess I can't help but hope someone reads this and actually learns something interesting about how software is made, at least in the context of a large multiple team project.

When you develop projects, there are going to be competing factors that ar in conflict. This usually comes up because different teams do different things and have dependencies on one another. Some work takes longer than other work. Also, some areas of a project are considered higher risk than others. Those areas receive extra attention from QA and code reviews. Those areas demand more time in testing. Areas that have not changed much get less attention from QA, but everything does get tested. You need to remember that the ultimate business goal is to create the best final release that meets product requirements. Nothing, let me repeat, nothing else matters. The good news is that VO is a product requirement and will be in the final release. But, it's just a piece of the whole. And you need to realize that other parts are even more important that VO. Yes, there I said it. VO is not important unless there are other parts of the product that VO works with. Put simply, if there ain't no screen,there ain't no need for a screen reader.

I can imagine how the project meeting whent that day and here is my fictionalization in the form of a play script:
Scene: zoom meeting with the Big Boss and team leads discussing the project at Apple.
Boss: (sounding happy) Excellent. iOS, iPadOS, TVOS all look good for the beta release, what's the current watchOS status?
WatchLead: (reluctantly) Well, all our stuff is on schedule, but as you can see on the project plan,VO support won't be finished for another week so theres some issues there.
Boss: I know, can it be released partially as is?
AccessibilityLead: I can answer that, no, it's very dependent on this last piece and it will be totally unstable if we do a partial.
Boss: Can we release with it disabled?
WatchLead: Yes, VO has a compile flag and we can build with it off without much risk. Heck, we could compile with a flag that removed all vowels. (awkward snicker)
Boss: Give me your assessment of risk if we delay a week for VO??
WatchLead: We need the feedback for the new complications framework. We need to get battery info on that one and the sooner we get it to masses the better. I still see that as our biggest risk.
Boss: Ok, this is a no brainer. Disable VO for this one. I don't want to do anything that will jeopardize the final release date. That cannot slip. Ok, let's move on to the critical bug list.

What the petition author and signers fail to understand is Apple's actual goal of the public beta does not depend exclusively on VO. The petition's position reflects a narrow, shallow, self centered view. It fails to see the goal is to make the best final product. VO cannot be taken in isolation. I fear that this type of frivolous petition devalues real issues we face with accessibility and makes it easier to dismiss valid concerns we have in the future.

As a project manager, I'd dismiss this petition in a heartbeat. I find it analogous to someone giving a product 1 star because it was lost or damaged in shipping.

For the record, I'm not arguing here, I'm just explaining why I'm right. Smiley.

Think before you post, and more important, think critically.