Who is the “you” in this comment?
I think Paul has made it pretty clear that it’s not going to be any of the current developers due to lack of bandwidth (and, perhaps, knowledge).
It seems to me that the primary thing you need to resolve here is a developer resource to actually work on a11y. Otherwise, all of the discussion of how it might be done is pretty much academic.
Cheers,
Keith
in this sentence, “we” are actual accessibility users.
Also I disagree. I think the first stage is to approximate the actual difficulty level, as I still think it’s believed to be even higher than it really is. Not saying it’s low, though…
Finding actual resources would be a second stage.
I understand that, but who are you expecting to do this work, given (as I understand it) it is specifically not going to be the current devs?
Which, frankly, is still a development activity, which requires developer resources to study the code and evaluate the options, approach, and activity/resources required. That is a significant piece of work in its own right.
And (at the risk of putting works into Paul’s mouth), whilst I’m sure the current devs might be happy to provide information to a developer doing this evaluation, I think they have made it clear they aren’t going to be the ones doing this piece of evaluation/design/scoping work.
The great thing is, as this is Open Source, anyone has access to the source code to do this evaluation.
But, one way or another, you need to identify a developer resource for this piece of work.
Once the evaluation has been done and the proposal presented, I suspect the current devs will need to be involved to comment on whether it’s going in the right direction (and whether a PR based on such an approach is likely to be accepted).
Cheers,
Keith
Sory to bother and for the late reply…:
My problem is not that there are no resources, my problem is I perceive what I see as a negative bias related to the fact that at least some developers think it can’t be done in a proper way because it’s not gtk, even if it’s not the view shared by all.
I can quote from one of the first posts here, not sure how to do it properly:
Ardour only use GTK for layout (and some checkboxes in the preferences dialog). Everything else in the Editor (audio regions, timeline), the Mixer (meter, faders, etc) or Toolbar (bindable buttons) do not use GTK at all. They are just items drawn on a canvas.
No problem with that sentence, but:
The closest you could probably get is to pass tooltip information to a screen reader, but that rules out most of the editor, too. Not to mention, plugins. VST, LV2 etc are not accessible either.
The way I read that last sentence is that there is an assumption that it’s not possible to do proper accessibility on such custom drawn items (in the sense of gtk-like experience) and you have to do workarounds like tooltips. That’s the reason I’ve done the above code example on github. It was not academick, it was to prove how false that sentence is, except the part about vst/lv2 plugins. It was also a first part of research which shows what are the external dependencies to add accessibility to ardour and what is the basic process. I’ve also learned these things myself which is a value by itself.
Above attitude very much influences the developer resources, as you’re more likely to not find resources for things that for you don’t really make sense. If that’s not what @rgareus meant when saying this, I’m sorry, but that’s how it was received by me.
As for ecasound/whatever being an alternative, is it even maintained? some sign is that fedora doesn’t even include it in repositories. I definitely know lv2 in ecasound was broken last time I checked. And if I wanted to use windows, I definitely would.
Also, replying further to above post:
The great thing is, as this is Open Source, anyone has access to the source code to do this evaluation.
The not so great thing is, that because number of blind linux desktop users is small, and because number of blind linux desktop users being also developers and doing sound related stuff at the same time is even smaller, the above is exactly the same as saying that it will most likely never ever be done before even starting the topic. It is way more likely to find testers or to receive valuable user side feedback. Adding accessibility pretty much always requires developer’s goodwill prioritizing this despite low number of requests, or being literally forced by law. Or being the target user of accessibility.
Accessibility is, by it’s very definition, not a low priority feature (I don’t necessarily mean it needs to be high priority because of it’s difficulty level in this case), but it’s developers who assign these priorities. Because blind user base is also small by definition, we have an unfair disadvantage over basically anyone else. Based on that metric, nothing would ever become accessible, especially not closed source software. Including ui toolkits. Especially ui toolkits. They had to put more work into accessibility than you ever would. You already work on a foundation even when doing non gtk stuff.
I don’t interpret it this way at all. The way I read the posts by the developers is not that it’s impossible, but that it’s pretty hard and a lot of effort.
So you’ve proven your own sentence to be false. But that sentence was an incorrect understanding of the situation.
No-one has claimed that it’s NOT possible, only that would be both technically tricky and a significant amount of work.
This then comes down to:
Of course. But that means:
I also don’t disagree, but priority is only one aspect. The amount of effort required is also important.
Ardour does not have much development resource available. Yes, the Lead Developer is the one who assigns priority, but this has to be done with some common-sense.
If developing a good level of accessibility in Ardour is something that takes (say) 3 man years, then prioritising it over other developments literally could mean that Ardour has no other developments done for 3 years.
In other words: no new features for 3 years, and no bug fixes!
If Ardour had a team of 30 or 40 developers working on it, they could probably get one or two of them to focus on accessibility without impacting core development and support too much. But Ardour only has a few developers.
In real life, development teams have to manage the backlog in a sensible way and priority has to go to important bug-fixes and enhancements. Does this mean they can’t work on accessibility at all? Of course not. But (in the environment of Ardour development)making changes to support accessibility can probably only be, at best, a tactical development activity where they apply some accessibility tweaks to parts of the system as they do other developments.
This isn’t going to result in significant accessibility gains any time soon (probably not in the next several years) but it’s really all that is practical without getting new developers on-board to focus on accessibility.
In other words whilst it may happen organically at some point in the distant future, if you want it to happen any time soon:
Of course it need a blind developer to do the development work. But it does need someone who is motivated to do it.
As I said before: that’s not the current devs. They already have too much on their plates just dealing with bug-fixes and smaller enhancements and, as I pointed out, it’s not rational to expect them to drop those important tasks to focus on accessibility, however desirable it may be.
Cheers,
Keith
Everything Keith said, with one proviso.
I am the “Lead Developer”, but I do not set priorities for anyone other than myself. I may encourage @x42 to do this or that, but there is no heirarchy of control involved. That is even more true for any other developers who might choose to contribute from time to time.
I hope I quote things correctly, i’m not used to discourse’s formatting and editor.
This is not the interpretation of the whole topic. It’s the interpretation of this specific post and possibly other posts made by that specific person, and it’s possible opinions of developers are not 100% the same even if conclusions are.
In addition, my perception is based on some discussion with me on irc few years ago on channel #ardour. I am unsure, to be fair, who I was talking with, but I remember that attitude even after a longer conversation. Including explicitly hearing something I interpreted as “these items on canvas are very visual in nature and so they aren’t really good for making them accessible” or something along the lines. And things like this. Because it happened long ago I might as well remember it wrong, but this lines up with the above interpretation, kinda. Other things I remember about that conversation also do. For example stating that “osara” which is probably an accessibility overlay for reaper, was possible in part because of some ms technologies linux definitely doesn’t have (it probably does?).
As you see, I might still be wrong, but this perception is kinda strong and I have reasons for it. If there are misconceptions happening here, then any discussions about accessibility, even added in distant future, becomes unrealistic without breaking them first.
I don’t necessarily mean I view it as believed to be literally impossible, rather impossible without actual major interface redesign, something along the lines of using gtk widgets everywhere or dramatically changing internal design. What I have in mind in this topic is not to make developers do it now, it’s to tell them it’s not that level of “hard”. Note it’s a wholy different bucket when compared to mostly additive changes, for example. This still means lots of efford, but it’s at a different level. In reality it’s probably not as simple, but definitely far from the other bucket.
If it were treated as the correct level of hard, it would at least be added to some backlog with a low priority. Is it? Maybe, that I don’t know.
See above.
For me this is a second step after actually putting it in the backlog and approximating required amount of work. Even if that’s rough approximation, I don’t think this has been done, which means finding resources is impossible unless someone else fully dedicated to it comes first. So we are in an infinite loop even if considering current devs could possibly find resources to do it in, say, a decade.
I don’t see it as needing to be prioritized over most other development. I literally feel as if it was explicitly underprioritized or out of the question until someone explicitly comes in just to do this. There are definitely things lower priority than accessibility, unless you have so few resources you stopped adding significant new features at all. Note that accessibility is something that can be added gradually over time. that work item can be split into many subtasks which don’t have to be delivered as one item. I don’t expect good accessibility next version. I expect situation to be improving. Not necessarily next version. And even if you really had too few resources to do even that, just considering to add it in a possibly unspecified future would by itself be a win over current situation. One step at a time, this is what I’m trying to achieve assuming no one from outside of the team just steps in.
Blind developer would be nice, but how many accessible products were actually made by blind developers or with their help? Most things, especially the foundation, weren’t… for obvious reasons. Sometimes this means lower quality, but it’s easier to fix lower quality than complete lack of accessibility, really. Unsure if it’s easier for few people deeply knowing the codebase to find time to do accessibility interleaved with other work than for one person to step in and do just that one thing without knowing codebase at all, considering that person might be in a similar situation. Note I am not sarcastic, I really don’t know who needs less efford, I am bad at capacity planning.
If we had a viable alternative it probably would be a different story. Do we? (see ecasound question). Also there is a reason most/many users prefer windows in general, so recommending command line as an alternative is not good for many.
There is really too much talk going on here for something that requires action.
Keith has excellently summarized the resource situation. No resources are going to be applied to this that currently exist. Any work on accessibility will have to come from someone/somewhere else.
If the work is done well (i.e. in accordance with our coding guidelines) it will be welcomed.
I am going to lock the thread now. If you get something practical underway, feel free to start a new thread.