Dear AppleVis Community,
We are pleased to announce that we have updated our posting rules to make them simpler, easier to understand, and easier to follow.
Since the very early days of AppleVis, our Posting Guidelines have been the rules of the road for participating on AppleVis. While our previous Posting Guidelines have served us well, the document has grown quite long over time as new guidelines were added and amended to address the various situations we encountered.
Our new guidelines, called the Community Agreement, have been rethought from the ground up and refreshed for today. The document is organized around four core principles:
- Be Kind
- Be Considerate
- Be Helpful
- Be Genuine
Each principle has bullet points that explain its meaning in language that is easier to understand and apply. There are also new sections specifically covering developer engagement, posting etiquette, moderation policies, and prohibited conduct - all areas that were previously addressed in some form or another in the old guidelines.
Key changes in the new Community Agreement include:
- We refreshed the language throughout the document, with an emphasis on simplicity and practical application.
- We reorganized the guidelines around four principles: Be Kind, Be Considerate, Be Helpful, and Be Genuine.
- We added practical guidance about constructive participation, including answering questions when you can help and not answering when you cannot, keeping humor and sarcasm useful and understandable, and not criticizing the spelling, grammar, punctuation, or writing style in others' posts.
- We updated our guidelines surrounding AI to reflect the current landscape and to specify how the technology can and cannot be used on AppleVis. AI tools may be used to help create or polish a post, but users are responsible for reviewing what they post and making sure it is accurate and still sounds like them. AI agents, bots, and other automated systems may not post on a user's behalf.
- We put in writing a previously implicit requirement that content be posted in English, while expressly welcoming the use of translation tools to translate a user's own words from another language.
- We added a dedicated section for developers that brings together existing and previously implicit practices, including how developers may discuss and share their apps, guidance on keeping app updates in one ongoing thread when possible, and the longstanding prohibition on developers posting their own apps to the App Directories.
- We clarified our existing rules surrounding sexualized content while specifically making clear that non-sexualized discussion of legitimate accessibility issues involving intimate material is welcome.
- We clarified the rules surrounding the posting of advertising, surveys, research projects, trainings, meetings, and similar activities. These types of posts are not permitted, although the AppleVis Editorial Team may choose to make very limited exceptions when we believe something may have particular value to the community.
- We brought a number of existing posting expectations together in a 'Posting Etiquette' section, including staying on topic, avoiding duplicate posts, using clear subject lines, keeping new topics focused on only one thing, and being careful when sharing personal information.
- We explained moderation practices that have evolved over time, including the use of public reminders for minor issues, private contact when appropriate, and temporarily pausing account access when necessary to resolve more serious situations or to protect the safety, security, and orderly operation of AppleVis.
You can read the full Community Agreement at https://www.applevis.com/community-agreement/. Questions, comments, and feedback are welcome. The Community Agreement is a living document, and we will take all feedback into consideration and update the Community Agreement over time.
Thank you for being here, and for being the best part of AppleVis.
Sincerely,
The AppleVis Editorial Team
Comments
Rules
Main rule if you do not care for a post do not read it and do not insult because you do not like it. People complain and go and cry about if someone does not agree. If I do not care for a comment, I do not read it or forget about it. AppleVis need to let those people that free expression is a must unless the person is attacking someone or insulting them. People are free to move on or go. AppleVis suppose to focus on input and providing help about apple producsts. Thanks for listening.
Cool
This is a much needed refresh. Thanks for all the work you guys do to keep this space welcoming. I basically grew up on this website, and in this community. It's still as vibrant and welcoming as it was when I first joined twelve years ago, and probably just as welcoming as it was when I got my first iPhone at an even younger age. I remember being new to smartphones and iOS and my mom handing me my first iPhone. I was cautious because I didn't think I would be able to operate an iPhone independently. Applevis was there to help get me started, and I'm so happy it's still here welcoming new users to this day.
Just curious
Why do you not allow developers to post their own apps in the app directory? Sounds a bit obtuse if you ask me. It forces the developers to hope and rely on other members of the community to add the app to the directory. If you ask me that's not fair. I guess the only thing I can think of for why you would do this is so a developer can't say an app is accessible when it isn't. But even then the comments on the directory post from other users would let you know what they think of the accessibility or lack of it. Maybe you should change that as well. Especially with vibe coding being more of a thing as time goes on senselessly prohibiting developers from adding their own apps to the directory is senseless control and nobody needs that.
Re: Cool
Yes, I agree, I recall when it came out. Now it feels different to me.
This is well needed
Thank you for all the work you guys do. However, these changes should've happened a long time ago.
As for developers posting their own apps in the apps directory, I do understand that. If a developer posts their app to the directory, there's a higher chance of possible bias, and I don't think anybody would want to deal with that. Obviously, there's always still a chance of bias, but it would be a bit less if a normal user of the app uploaded it instead of the actual developer.
One thing that's cool to see is the development of the site. Go on the way back machine, type in the URL and go onto the earliest snapshot of this site. Shit is so much different compared to what it is now it's insane!
Re: Just curious
Hi Tyler, thanks for the question.
AppleVis started out as a place where people could come to review apps based on their accessibility. We do not allow developers to post their own apps to the Directory because an App Directory entry is a review in everything but name. With the best will in the world, a developer's assessment of their app's accessibility is not going to be as objective as that from a user with no vested interest in the app. I would liken it to a company writing product reviews on a shopping platform.
Thanks again for the question and feedback.
Yeah I kind of figured.
Yeah, I kind of figured that, but my thinking is if the developer is blind they know how to make accessibility part of their app because they need it in order to test it themselves. So in that situation they should be able to put their apps in the directory. It shouldn’t be black and white banned completely. I don’t know, that’s just me, but I see where you’re coming from
Re: Rules
I totally agree with your point of view, thank you so much for bringing it up in your comment. I have been a victim of such instances. However, I let things go easy; water under the bridge. Have a good one!
I see two sides to it
Personally, in my view, I see two sides to it.
I'd like to note that in no way am I criticizing those with sight by presenting this view. I'm more or less, seeing it from a different angle.
I think the app directory entry rule really only makes sense if someone does not use VoiceOver as a daily driver, or is not blind, low vision, or DeafBlind. I don't think I'd want to make my apps or games inaccessible on purpose. How does that benefit me? I'm blind, after all. 😀
I guess where I'm coming from is, I think it comes down to clarity. A developer who is blind, or has generally worked with the AppleVis community for so long that accessibility is evident, I think there could be some justification there.
Now I'm not saying open the flood gates and allow posting our own apps and games. I'm more or less saying, there are several ways to consider this, and the guideline takes only one of them.
Sorry if this didn't make sense, it's almost 1 AM at the time of this post so I'm sort of scrapping this altogether.
Great Job AppleVis + A Quick Question on Bug Tracking
I wanted to take a moment to say a huge thank you for the incredible job you do in keeping this site so informative and fostering such a wonderful community. It is a space where members not only benefit from the rich resources available, but also actively engage with one another. I deeply appreciate how user feedback is respected, and how clarity and support are always provided when needed.
I also had a great new experience on the site today: replying to a comment on a post and seeing it neatly threaded directly to the original comment! It is wonderful to see the platform continually improving—keep up the fantastic work!
I did want to ask a quick question regarding the community bug program. I regularly report my accessibility challenges directly to Apple Accessibility via their support email, providing them with screenshots, video recordings, and system logs. However, managing my time has been a bit challenging lately, and I noticed that the bug report form asks for an ID starting with "FB".
When I correspond with Apple Accessibility, the identifier I receive in their email replies is formatted as a standard Case ID (for instance, looking like a numeric string such as the ones I receive). Is this Case ID the same thing as an FB number, or is an FB number generated differently (such as through Feedback Assistant)? Any clarification on this would be greatly appreciated!
Thank you all again for everything you do.
Re: Great Job AppleVis + A Quick Question on Bug Tracking
The FB number is the number generated when reporting a bug and the Feedback assistant app
Re: I see two sides to it
Hi Tunmi,
First and foremost, I appreciate your feedback and where you are coming from.
When thinking about this and the points raised by you and Tyler, I keep coming back to the fact that an App Directory entry is essentially a product review. And with the best intentions in the world, an app's developer is not going to have the same independence as someone with no ties to or vested interest in the app.
For example, when we launch our AppleVis App in the next few months, our team will not be adding it to the App Directory ourselves and will instead hope that someone in the community will review and add it. We are really excited about the app, and we have put a ton of time and energy into making sure VoiceOver support and everything else is the best it can be. But we also cannot review our own work independently and objectively. Of course we think it is great!
While I would love to relax this rule, I just do not see a way around the independence/product review component without significantly compromising the integrity of the App Directories.
I agree with AppleVis's policy concerning the App Directory
I think it's a smart policy to only allow the community to upload vetted applications to the AppleVis App Directory. I would add one caveat, however. Perhaps add a web form to the site so that developers could submit their projects to the editorial team for review? The team themselves would not have to necessarily be the ones to review it, but it would be a way for developers too submit their projects, and possibly expedite a review.
Just a thought. 🤔
I like the policy as it stands.
Michael's explanation of this policy makes perfect sense to me. Developers are free to post about their apps in the forums, and then, a non-developer member of Applevis who has used that app can post a "review" to the directory. The developer's post to the forum can contain all of the information that would be included in the directory entry. I don't see what would be gained by allowing developers to make directory entries for their own apps.
Good stuff
Dev feed?
I've noticed that there are a lot of calls for beta testers, myself being among them. I'm just wondering if this might be diluting the quality of the main page and perhaps burying questions and that sense of general help AppleVis is so good at. Just a thought or maybe something to keep an eye on. The issue could be if there are too many posts per day, many posts by people seeking help might be swept off the board before people get to answer.
Re: I see two sides to it
I think I agree with the Applevis stance to be honest. I'm not sure that just because an app was developed by a blind developer means it is accessible or worth using. As an example, when Quill - the screen reader first text editor - was released on the Mac it was clear that it had only ever been tested in Windows as it didn't even really work at all. And now it still has fairly serious accessibility issues (e.g. try selecting text in it) I'm not wanting to single out Quill in particular as it's still a beta, but more the feeling that you can ask an LLM to make an app multi-platform but then that doesn't mean it works. Or you can write an app with a billion features in it, but they won't all be tested and some may never even have been used by a human at all.
With vibe coding it's almost too easy to put something together and then just throw it out for everyone else to test. I would rather the app directory didn't get flooded with hundreds of barely working vibe coded apps. It's not that I'm against them as such, and I don't want this to go into a vibe coding debate again, but I would like apps in the directory to have a certain level of quality and commitment that isn't true of all vibe coded apps.
For example, Claude can write me an app in an hour and I can then, throw it out to everyone, get bored and never touch it again. That sort of thing doesn't belong in the app directory. I worry that there is almost too much of this sort of thing. The problem is that there is an initial empowering rush of adrenaline that can soon subside when the app turns into actual work. I'm not saying all apps developed this way will go in that direction, but I am also waiting to see how many of them really stick around.
I think devs are free to post about their apps, and it's great when they do, but the app directory is maybe a little more of a seal of quality, or a warning depending on how good the review is.
Anyway this is just my opinion and I am not knocking yours.
The only thing I would change about the app directory submission form is that sometimes I can read it and still not really have any idea what the app is. The description comes from the app store listing, and there are comments on accessibility, but often I'm still left in the dark about what the app actually is and what I might use it for.
Anyway, I like the principals the new guidelines are based on and would like to say again how much I appreciate that we have this wonderful site.
Re: Dev feed?
This is a good point.
To be honest, these days I do feel pretty overwhelmed by the endless new app announcements. I am interested but it's just getting a little too much at times. I personally have no particular interest in beta testing someone else's app - I don't mean that to be rude it's just I know I can't devote enough time to it and the thought of having to fill in more bug reports depresses me. Obviously not everyone feels that way which is lucky. :)
We have Applevis Unlimited which is great for highlighting actually finished apps. This month in particular there was a load on there I wasn't aware of and I check this site all the time.
But it would be a crying shame if genuine questions were getting lost. I don't know how much this happens but it might be nice if there was a way to surface something that hadn't been answered.
Re: Dev feed?
I’m not a really technological person. I come here to look at the app directory to see if there are any useful or fun or interesting apps that might be worth playing with, and also to look at questions that people might have that maybe the same as what I have but haven’t got round to posting yet. There is just so much content, and particularly content for people who are advanced Apple users, or people who want testing for a new game or app or ideas for an app… I do feel that general questions kind of do get lost. The simple, how do I turn my phone on, type questions seem to be swallowed up by all the developer request and advanced content. just my inarticulate, non-technical opinion.
I have to agree with that
I have to agree with that. I’m not super technical either. And a lot of times there are developers coming on here with lots of app testing request. Something like that I think a lot of the general questions to get lost. I’m not really sure how you would divide the website up to change that I have to agree with this previous comment.
applevis app
will the applevis app only be on ios?
App-Testing Posts
Hi all,
First, a huge thank you to everyone for the feedback and questions.
The idea of a dedicated place for developer/app-testing posts is something we have never really thought about up to this point but are definitely open to considering. While we love that developers choose to come to AppleVis to share and get community feedback about their work, we hear you about the influx of developer posts. We would greatly appreciate any and all input/suggestions on how we might solve this, whether or not you have already commented previously.
Re: applevis app
Hi Ziixies,
Thanks for the question. At launch, the AppleVis app will only be available on iOS, with other Apple platforms possibly coming later. We will not be releasing the app on non-Apple platforms.
The problem with an app testing forum.
It would be simple enough to add a forum or forums for app testing. The problem is the "latest posts" section. I don't know about anybody else but I pretty much check that, because I assume I check often enough that most stuff will show up. I rarely go into the individual forums. What that means though is that dev posts will still show up there. So all your general questions will still get lost.
One solution might be to expand the latest section, with headings pulling X number of posts from each forum. If it could be dynamic so only forums with new posts would show up, even better, but even if you just did each forum, it would be easy enough to skip over ones that are the same.
That way, if you didn't want to see dev/app testing questions, you could just skip them. I'm not familiar enough with iOS to know if you can do heading levels like you can on other OSen, but on desktops anyway numeric navigation would make this pretty simple to navigate, e.g. forums at level 2, posts at level 3 or the like.
Re: The problem with an app testing forum.
or you could have an option to filter the latest posts section, tbf i think you alr can but you could filter by apps foroms toppics, or help or something that has nothing to do with apps
Re: App-Testing Posts
Banning all the AI slop would certainly help, as that seems to comprise a significant portion of the app postings and testing requests recently. We can't always audit people's code, but we can at least audit the posts concerning that code and throw away anything that's obviously not human-written.
Re: The problem with an app testing forum.
Or could you do like a latest post section, and then under a separate heading a latest testing request section.
Re: The problem with an app testing forum.
I feel like that would make the place a bit more clutterd then what it is all reddy
I think they should be app testing forums
I think they should be app testing for him for an existing app and then maybe like an app beta testing forms or something similar to what we already have for like the Apple Pay releases. I’m not sure exactly how but that’s the best I can come up with right now that might make even more searching on the website itself so maybe we don’t wanna clear it more with further form settings, and topics I don’t know.
Re: I think they should be app testing forums
i feel like if you have an account on the sight you should be able to hide serton toppics from showing up.
like i don't use braille, and i'm not low vision. i don't want that cluttering up my applevis posts feed
Yeah, that makes a lot of sense
I’m the same way. I don’t have any vision and I don’t use Braille with any of my devices. I could totally see why somebody may want to hide those kinds of posts from their account specifically. I didn’t think of that, but that makes a lot of sense to have that ability. I’m not sure how you would execute it, but that is a great suggestion.
make an app development testing forum
Have developers who want users testing their apps go to app development testing forum and call it a day. If you can pull topics from apple and non apple posts as of recent you can do the same as within the app development testing forum if you so wish and people can go under that specific heading just to see them posts within heading three. that or they can philter if they really wanna see what's in there. Not sure why this has to be so complex just sayin'. Why make devs do more work than they have to.
Re: I see two sides to it
Is the app gonna be on Android at some point too?
Re: I see two sides to it
i'd hope so.
whilst i'd understand if they won't i'd still be very dissipointed about it. i don't have any apple devices besides my mack, and i can't download apps from the appstoer because it's not accessible so.
Re: I see two sides to it
Hi Joshua,
Thanks for the question. While I realize this may come as a disappointment to some, we will not be releasing the AppleVis app for any non-Apple platforms.
Thanks,
Michael
What enspired this?
I’m just curious as to what inspired you to create a dedicated app for this, when the website works perfectly well. The only thing I could think of that would be beneficial as far as an app goes would be actual notifications when somebody replies to your posts or something, but you can still get those via email, so I’m not really sure what the point of creating a special app would be
AppleVis
Agree with previous comment. Not getting it. I check the web page in my window 10 PC. Right now I am typing on it. However to each their own.
Re: AppleVis
I also won't be getting it, not that i have much of a choice in the matter because i don't use an ipHone.
look, i understand you wonna do this but would it of been a good idea to ask menbers of the sight if they were keen on it? because being reel, what's the point of spending $100s of munny on an app that you arn't sure of if it will even get the amount of what you want, when there's a lot of things you can spend that munny on for the site.
again, no hate or anything im just asking from a Financial perspective
Subscription
I see the future for the app, can you say subscription!!! It might coming one day.
Re: Subscription
yeah i wouldn't imagine most people paying for a subscription to the applevis app unless the site were to be placed under a subscription modle as well, witch surely they wouldn't do as i feel like that would Alienate some people who might all reddy hav greevences with this platform to go to another platform, or, time permitting, starting there own website against applevis but for free.
just my thoughts, but because we are making assumptions i thought i would chip in with my own
Inspiration for the App
Hi all,
Since the very early days of AppleVis, our top most-requested feature by far has been a native iOS application. Until recently, it wasn't anything we could ever deliver on, because we felt quite strongly that if we did an app, it would need to be fully featured. The primary audience is people who use either their iPhone or iPad to access and engage with AppleVis—the only really way to do this currently is through Safari or another web browser, which is not ideal if a native experience is available.