Thoughts on responding to NFB 2016-04, who is responsible for making apps accessible

Hi,
As I read responses to NFB resolution 2016-04, I'm reminded about the state of accessibility of universal apps in Windows 10, particularly more recent releases posted on Windows Store. While I do see potential of this platform, I'm still unsure as to whether our suggestion on improving accessibility was received and acted upon by app developers. This is more so now that Microsoft is shifting focus towards shipping Windows 10 Anniversary Update (aka Redstone 1,Version 1607), as there are certain places that are still not labeled correctly, presents challenges for some audience members and so on.
One of the crown jewels of any operating system is third-party programs. Thanks to various API's in place, Windows, OS X (recently renamed to Mac OS), Linux and other operating systems allow programmers to take advantage of possibilities offered by API's, thereby enhancing lives of people through their apps. But we're seeing a trend where quality is sacrificed in the name of polished user interface, some of which affect accessibility. So the question becomes, who should be responsible for making apps accessible?
Before answering the above question, I believe it is important for us to remember that software development is a collaborative process. If a software is going to be used everywhere, communication between users, designers, developers, testers and outsiders is essential. Users should tell software developers what they want and need; developers should be ready to listen to feedback from users; designers should work closely weith coders and users in finding a balance between functionality and appearance; and testers should be willing to act as ambassadors between users and developers in finding potential issues.
In case of accessibility of application programs, it is crucial that users, assistive technology vendors and app developers (and sometimes, operating system architects) should keep fruitful channels of communication going. Users should be willing to give feedback to app developers, telling them exactly what's going on and providing helpful suggestions. Developers should be willing to listen to feedback from potential customers, including those with accessibility needs. Finally, screen reader vendors should facilitate communication between users and developers in providing their expertise to developers on best practices, and to let users know that they are not forgotten.
First, users should be willing to learn how to submit practical and constructive feedback. Just saying to others, "I want such and such features or found a bug somewhere" does not really qualify as feedback. Ideally, a feedback communication should include the name of the app in question, steps to reproduce a problem, expected versus actual outcome and helpful suggestions or workarounds. Also, after submitting feedback, users should be willing to provide follow-up information such as clarification, thoughts on workarounds and so on.
A particular point to consider is attitude one sees when user submits feedback. If it comes off as rude, developers would not be able to understand the true nature of a feedback (remember that developers are humans, too). If a feedback was given without steps to reproduce a particular problem, developers would not be able to pinpoint the code path that causes a bug to surface. If users don't follow up with developers, it becomes just a one-way street (feedback is a multi-way stream).
Second, app developers should be willing to listen to feedback from customers, including feedback on accessibility. Although a recent NFB resolution mentions quality issues with iOS and Mac OS releases, I believe it applies to app developers as well, particularly on Mac OS, Universal Windows Platform (UWP) and other platforms, as people with disabilities are a rising market force in software consumption.
A particular serious case is Facebook UWP. Despite numerous suggestions to Facebook accessibility team and tests, as of July 2016, Facebook UWP isn't accessible (rather, introduced accessibility regressions). For example, while using Facebook UWP, under some circumstances, one cannot use object navigation and similar features in various screen readers to navigate to various parts of the app (unfortunatley, this affects Narrator users as well).
This brings us to the question posed earlier: who should be responsible for improved accessibility of apps? I would say both users and developers are involved, but I would put greater emphasis on developers. As consumers, users are responsible for providing practical feedback to app developers and operating system architects in hopes of making various parts of an app (or an operating system) accessible. Developers are also responsible for this, as they should be willing to work with users in identifying issues, learn from others and provide fixes so users of various assistive technologies can use their apps and be drawn to them.
So where does screen reader developers stand in this picture? As they are both users and developers, they should serve as communicators between users and developers and provide guidance to both parties. If app developers are willing to listen to users, screen reader vendors should encourage users to send feedback to app developers and let app developers learn from other programmers in making their apps accessible. However, if app developers are unwilling to listen, screen reader vendors should serve as an understanding advocate for users, letting fellow app developers know what's going on and offer assistance upon request from the viewpoint of a fellow developer.
I'd like to conclude by asking those debating the merits and outcome of NFB 2016-04 to not send out words out of passion. Although I respectfully disagree with the resolution (which was passed), I'm concerned that we have found ourselves sending words back and forth out of passion rather than calm reasoning. As someone who have tried public iOS betas and am a screen reader contributor, I do understand that Apple is trying its best yet has quality issues in recent iOS releases. I think rather than having perpetual flames, it is better to teach others how to give practical feedback, as this not only helps Apple, but also helps consumers in the long run. The more feedback Cupertino (and Redmond, Mountain View and others) receives, the probability that we'll meet a more polished iOS (and Windows, Android, etc.) release (and apps) increases, as users and developers have their share of responsibilities when making apps and operating systems accessible for people with disabilities.
Thanks.
//JL