Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index

Op 28-10-2020 om 08:29 schreef Quentin Christensen:
Thanks Florian,

Given the increasing use of open source software such as Libre Office in
government and corporate use, it is disappointing it isn't more of a
priority.  Not being accessible does explicitly exclude LIbre Office from
most government use for instance.
   I understand the difficulties with not
having any paid developers you can direct to do particular work, but it
does make the product specifically impossible to use for large segments of
potential users.

There are multiple factors at work I assume
- They group of users of accessibility (no-offense) is relatively small.
With less of incentives (getting different at the point being a pre-requirement for governments/NGO)

- Most/All Developers themselves don't use accessibility (I speculate)

- There are not many people at QA/UX who have knowledge about (or use) accessibility tools structurally (I assume) And if they do they might have the actual handicap (so paying less attention to the stuff being a problem)

- There or not many reports of accessibility bugs (I think)

- LibreOffice being in principle being developed by Selling Developer Time (instead of final 'product' with certain functionality) And there is no centralized organization paying. So this tends to put on hold.

I'm personally and advocate for more bug fixing (or in general quality control). Nobody is inclined to pay for solving bugs. Everybody expects someone else will do. Or work around it. Hurting the general user experience. In my vision there needs to be an upfront investment (financed by eco-partners) with a (substantial) higher product price, to make returns on investment. This would also make it possible to embed some kind of solidarity. The revenue - payed by all users - can be used to serve a niche (accessibility). Instead of a niche having to pay to full price; which doesn't make sense for the broad audience.

Same hold true for bug fixing. About bug XYZ a user ABC might not care but D does. So not likely to get solved. Or D has to pay. However, nobody actually knows if there is only 'D' or a bug is simply under reported. People try LibreOffice,
notice it fails on their needs, and move on.

However they approach is for developers more easy to manage. Investing in advance has a risk of failure, if you don't estimate the desires from users properly. So you make no return at all. And you gets of debates/arguments about priority's. What should we do next.. And everybody will come up with something. Having different accents/visions. Say there is a budget for fixing 100 paper cut bugs and lets say we have 3000 of those. File Export has multiple flaws. A single paper cut bug fix, still leaves a broken feature. So pretty pointless. To make worth the effort 5 needs to fixed. But who uses File Export. Why File Export and not 5 accessibility bugs. But there 100 accessibility bugs; which should have priority

I wonder how other FLOSS projects handle this?
Me too. It sounds like it's functioning there? Any examples?

Kind regards


On Wed, Oct 28, 2020 at 5:59 PM Florian Effenberger <> wrote:

Hi Quentin,

Quentin Christensen wrote:
Was there any discussion about accessibility and if so, did anything
come out of it?
there was no separate discussion about accessibility. It is one of the
topics the board has in their ranking, to determine the
importance/priority of the topic - but we didn't discuss it in detail.



To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.