Become friends with developers

As a visually impaired individual my self, I encounter accessibility issues Nearly every day.  For example, websites, apps, and services can be difficult to navigate If it has   inaccessible interface or navigating with screen reader is complicated. As we know, it is the responsibility of the developer to make apps and services accessible to the blind or visually impaired individuals.

I wrote an article a while back, and I tried to answer the question: How does one fix accessibility issues? I said that the fix for that is “education”. I still stand by that, but as I mentioned earlier, it is the most reliable way, however the downside of that is it takes a lot of time to achieve that. So, the point of today’s article is to give another solution that does work, and explain reasons why that is the case.

In this article I will refer to developer as a person to which we are sending usability issues regarding accessibility, it might be the developer himself, but in many cases, it might be a customer support. In many cases we do not have ability to have direct conversation with the developers of the application, but the suggestions and my thoughts I am about to give could be applied in whichever scenario you are in when reporting accessibility problems.

Being friends with developer?

Being friends with the developers is my way of saying I report accessibility issues to them in a polite and clear manner. Being friends with the developer doesn’t mean that you have to be friends with the person who is a developer of the application, However, it means that you have to provide information about accessibility issues you encountered by using Easily understandable format and nonjudgmental attitude.

My reference to being friends with developers born out of the idea, if you’re angry, disappointed and you’re Letting out your frustrations away to the developer, it just won’t help at all because he or she does not understand the problem at all in many cases.

So, by being disappointed or unreasonable you are closing the doors to the helping hand you may get from the customer support or the developers themselves. In order to be a good resource for developers, you must be friendly and polite. By being friendly, you are becoming a resource to the particular developer that can help to solve accessibility issues for you and by providing information in the right format, you make it easy to the developer to understand your issue.

No matter how frustrating or annoying the issue is, and I do understand perfectly that sometimes it feels absolutely not fair, and in many cases it is. Explaining accessibility issues to individuals who never use the software before is a hard thing to do, thus, sometimes it takes a good bit of conversation to achieve the result.

I think many users or developers themselves would agree with statements that developers don’t break accessibility because they want to, it happens because they have no knowledge of it, they never learned that in school, there are no easy way to tested properly other than being a screen reader user yourself. It is hard to be one, if you not using a screen reader application every day, so thus it becomes harder to test for the accessibility issues.

Ideally, they should know those issues and they should understand how to provide accessible user experience and so on. As mentioned before, its education issue, but not only that though, the business perspective of this problem also exists and it is related to finances and customer userbase. Companies do not gain financial extras by implementing accessibility fixes into their services, because screen reader user base is small, so thus, it is not worth to spend large amount of cash and resources to fix the problem to satisfy very small majority of customers needs. On top of that, fixing accessibility issues after the project is complete is definitely expensive to do.

So, to summarize business perspective, it doesn’t provide any value in terms of income, and it costs a lot if it’s not done in the starting stage. That’s the reason why it is difficult to improve the existing services. It is way easier to start with accessible interface in mind. That happens only if there are resources and people who do understand the usability issues when using a screen reader application.

The sad truth is that even if there is capability to fix the issues, they are not in the highest priority of to do list. If course as I mentioned in my previous article another way to fix it is implementing standards and very clear guidelines, but that is also hard to achieve because there are too many developers who have no clue how to do things to their apps and services to make them accessible, so therefore it is not very feasible idea to just introduce this kind of requirements and one day, because without a doubt 99% of applications would not be able to satisfy the accessibility requirements simply because they are never taught how to do such things in college. And everything starts from college and education.

as This article suggests, there are things we can do and that is to become problem reporters / educators ourselves, but for that to happen it needs to be done right and others need to take responsibility. The problem with accessibility reporting is that for one not many people do know how to do it properly, and 2nd, not many people feel it is their responsibility to do so.

Well, for one it is your responsibility to do so, and 2nd, if you want to be effective you have to know how to do it properly. Let me explain myself.

If the education regarding accessibility is not there, it is your responsibility as a user to educate the developer. And yes, in theory there should be education and guidelines, a lot of other things in that matter, however it is a job for now for all of us to try hard to fix those issues. By becoming a problem reporter, you are essentially becoming an educator to the developer, and your knowledge and explanations will be used to improve the product.

From users’ perspective I am getting frustrated, and i do understand your point, I am on our side, because I encountered those issues myself as I mentioned at the start of the article. However, from the developer’s perspective, I know nothing about it and I never encountered such issues before.

So, in this argument both sides are correct, and they are both right, because it is frustrating for the blind or visually impaired user, because he or she feels like left behind and can’t use the service, but from developers’ point of view he or she does not know nothing about it.

So, the conclusion to this problem is education, as I mentioned in previous article, however, if we want to improve this problem it is the responsibility of ours to be more proactive in issue reporting, particularly if you like the service and if it is very useful application to other blind or visually impaired individuals.  we have to take the education responsibility to our own hands until the standards and procedures are improved.

My tips how to report issues correctly

  • always report the expected and unexpected behavior, the reason for that is the developers need to know what you expect from the element, or elements when they are accessible. If your report something like my screen reader does not read something, the developer actually does not know what you mean, simply because he never used a screen reader before.
  • Clearly explain which elements are not accessible and exact element location, The reason to do that properly is for one the developer cannot have any doubts which element you are reporting, and 2nd you have to provide the element location in the easy-to-understand format.

For example: if we are talking about some kind of app and inaccessible button in the login form

“home/sign in/forgot password”

Would be the correct way to provide the exact element location.

so essentially by using the website URL format you are using the format that is already understandable by developers and there is no way to misinterpret the elements’ location. It is crucial to use consistent formatting, because when reporting problems with accessibility we have to make sure that developers are referring to the same elements and have no misinterpretations where the issue exists.

  • It is always a good idea to give as much information as possible in the well-organized format. If something does not work and it was working before, please make an effort to find out which version broken accessibility.
  • If there are ability to attach logs, please do so, because they do exist for the reason. Those logs do provide extra information to developers about what you did and what happened. Essentially, logs do provide contextual information about everything you did in the app, in simple terms it acts as a journal that keeps the record of user interactions and program events, and no doubt those logs become useful when bugs do occur.
  • If you have ability to record the issue while using a screen reader live, it is 1 of the best and easiest options to follow the issue for the developer.
  • If the app is partly inaccessible which is often the case, you can provide the location to the elements that are accessible, by doing so, the developer can look into the code and see what kind of properties that element has, and thus compare the properties with the nonworking element.
  • If you are encountering the contact person to be not technically savvy or more likely clueless about accessibility issues, please provide information that can be forwarded to the developers.  In many cases, when I realize that the support has no clue about the issue, I always let the other person know that it is not his or her problem to fix, however I always mention that I would like to give information That can be used by developers to solve the issue. In my experience though, if it is a software or app company, they just ask the questions that they are trained to ask, in which case the information they are asking you to provide is enough for developers to investigate the issue.  However, if it is a website for ordering some kind of services, individuals working there in my experience don’t have as much knowledge about the technical requirements and so on.  So there for it is up to you to provide all technical information

Very Often developers ask for screenshots of the particular window where the issue exists, and it is quite tricky for us to highlight the issue in the screenshot.

But wait, there is a very important tip that I figured out recently that will help you to highlight the problematic element either in the video or in the screenshot. My solution to that problem is to use the cursor highlight option in your screen reader, because then there is a highlighted rectangle around element you are working with. I can think of at least 2 benefits that are absolutely useless to the blind individuals, but it is very useful to individuals who are following what you do with your screen reader. This particular feature is aimed at low vision users so they can track where cursor of the screen reader is, but it is equally effective for blind or visually impaired individuals when reporting the issues.

  • You will be able to highlight the area using your screen reader, and take the full screenshot and thus highlight the problematic area.
  • when recording video, the person watching will be able to follow where your screen reader is, if person is not able to follow your actions or understand what your screen reader says, he or she will be able to inspect visually the element you are on.

Accessibility issues for developers

As we know, absent services have different types of elements which include buttons, checkboxes, edit boxes, scrollbars and so on. elements have different kind of events: like labels, on click events, hover state, scrolling, and so on. It really depends from the element type what kind of properties it has.

Some type of user interface elements is more accessible than others, for example checkboxes and edit boxes, are more accessible than charts, calendars, sliding elements and tables. The reason for that is that some elements require more interaction than others, and it is easier to interact with some elements for example when using forms, we are going from top to bottom, however, when we are using tables, charts or calendars the element could be in the middle of the screen or at the very bottom, which is complicated for screen reader users to find and interact with.

Sometimes accessibility issues are not a fault of the developer at all, in those instances it is likely the issue with the UI elements, framework, or lack of other information in the development environment itself. In that case, it is very unwise to fix the accessibility issues, because in those instances developers need to rewrite the UI to fix accessibility problems, in which case the developer is in a lot of trouble, and we are likely not getting the fix, because developer cannot do anything about it if the framework is inaccessible. in some instances, it may require to change the entire code base that manages the front-end of the application that made be as much as 50% of entire code base.

So fixing accessibility issues becomes a very slow and very expensive operation with no financial gains

It Is quite easy to recognize the above-mentioned issue, because there is one big indicator, and that is the entire application and its elements are not accessible at all. In my experience it is very rare nowadays though.

If the app has partial accessibility, ,  it indicates that the framework is accessible, it is the developers lack of knowledge as it is often the case why accessibility is the problem.

Most frameworks are using standard elements which has accessibility properties, and accessibility is included and can be implemented as part of the design and thus the application can be made fully accessible, only though if developer takes time to think through interactions and user experience. more graphical applications with unusual elements or custom graphics in particular with some of the UI frameworks can be troublesome which renders the app components inaccessible by default.

For now, there are no standards, penalties, and good education to wipe the accessible design problem, so therefore, it is the responsibility of ours to report the accessibility issues. I personally report problems I experience with the services I use, even though it’s hard and takes time. Personally, I believe it is the responsibility of mine and I always worry if I didn’t do it, the problem might never be solved.

It is fantastic when companies like Apple, Microsoft, and other big Giants have the entire division dedicated to accessibility as a result of that, it has proper testing, validation, and implementation of accessible user experience.  Otherwise, it is a rather nonexistent priority and   small to medium size companies have issues and no resources, knowledge, and extra budget to provide accessible user experience.

Let’s be clear about one fact the majority big and small companies do not have education and resources to test for accessibility issues properly, particularly when we are talking about screen reader accessibility and usage. I will repeat myself one more time it is the responsibility of ours to help the developers help us, and that means we have to be friends with them, take some personal time and do the right thing which requires to educate the developers and help them with feedback and patients, even though it is frustrating and feels unfair.

Another idea just came to mind as I was finishing this article, I will gladly add our readers experiences in the reporting tips section as long as the provided info is not a duplicate of mine.