palemoon is'nt accessible for blind users. Topic is solved

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
pax19

palemoon is'nt accessible for blind users.

Unread post by pax19 » 2021-01-08, 12:57

Hi.
I really wanted to try it out, but NVDA dont reads anything in there.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: palemoon is'nt accessible for blind users.

Unread post by Moonchild » 2021-01-08, 13:47

That's actually not a bug, it's by design. Pale Moon has never included support for specific accessibility hardware, and if you need it to interface with e.g. a Braille rule then it may not work. If you are in need of that kind of accessibility functionality, then this browser is simply not a good match for you.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

pax19

Re: palemoon is'nt accessible for blind users.

Unread post by pax19 » 2021-02-19, 21:55

I don't use braille.
It's trash for me.
I prefer to use speech.
But it's shame that we can't use this one.

User avatar
Bilbo47
Fanatic
Fanatic
Posts: 234
Joined: 2017-11-18, 04:24

Re: palemoon is'nt accessible for blind users.

Unread post by Bilbo47 » 2021-04-11, 02:46

How much of W3C's recommendations/guidelines for 'web accessibility' or 'accessibility features of html' does Pale Moon cover/support? I mean, that's almost as large a question as 'How much of the spec for html/css/etc does Pale Moon render correctly?' If we compared PM against say current FF/MSE/GC for 'accessibility' then how would they all stack up?

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: palemoon is'nt accessible for blind users.

Unread post by Moonchild » 2021-04-11, 06:55

Why don't you put in the time yourself to answer this question?
This is almost Latitude-level random question asking that implies a major time sink. I'm not falling for that any longer. If you're curious, then you can find it out yourself by doing the legwork, too :)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 4942
Joined: 2015-12-09, 15:45
Contact:

Re: palemoon is'nt accessible for blind users.

Unread post by moonbat » 2021-04-11, 10:57

Before ever asking a question in the forum, the most basic homework you can do is read the general information provided on the main website. It covers everything from the purpose of the project to what it stands for and doesn't stand for to technical specifications, system requirements and how it differs from Firefox.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
Bilbo47
Fanatic
Fanatic
Posts: 234
Joined: 2017-11-18, 04:24

Re: palemoon is'nt accessible for blind users.

Unread post by Bilbo47 » 2021-04-14, 03:55

... put in the time yourself to answer this
Yes you're right. Let me shrink the scope. What is the project's intended goal relative to accessibility? TlDr at the bottom, lots of rambling next.

One assumes that all browsers intended for general use are aware of the relevant so-called requirements that apply to all software and computer systems pertaining to the web. However many web developers are "not aware", and fail to add elements to their web content as basic and easy as image descriptions in <img alt="tags"/>. The 'wizards' and web-dev toolkits that perform "Add Image" with a dialog box are getting pretty good at requiring alt-tags as non-optional.

It is an OS's job to support system-wide features like screen readers and voice commands in place of text output and keyboard+mouse input. Even proper graphical controls are 'rendered' into audible information. Thus general-purpose apps can take advantage of 'extra' accessibility features with no extra development effort. The OS also supports/integrates drivers for add-on hardware, so that general-purpose apps end up likewise leveraging the extra hardware's functionality merely by virtue of the fact that they used the standard OS APIs, which the drivers hook into.

A poor alternative would be to fork some open-source projects and integrate specific hardware peripherals with them ... but it would be better to do that integration at the OS/driver level, so that all apps can use the hardware.
Off-topic:
Historically there have been a few notable exceptions of extreme accessibility fails. In particular a CBT Computer Based Training development platform that wanted to be the Java of its field by hosting its apps on all targeted OSes with zero changes to app source code. The design fail was, they did not use app-level APIs provided by the OSes. Instead they built their own overlapping windowing system, obviously with a whole set of custom controls and APIs for their client apps. (One selling point was supposed to be the identical look and feel of the apps from one OS to the next.) Presumably at some level the platform also wanted to avoid its own code changes between OS platforms, as much as possible. Obviously the several windowing systems ended up being much much slower than native apps (by native I mean apps that called the proper APIs properly; such APIs are naturally different between OSes).

The market fail they didn't think of was accessibility. The OSes didn't see the platform as a normal app, because the platform called no APIs into which Windows for example had built accessibility hooks. None of the training programs hosted on the runtime version of the platform could be made accessible. The company quickly built and tried to market an add-on accessibility module, at extra cost to developers and/or end users, again implementing a proprietary system to support accessibility features. Yes, all the training apps had to go back and update their programs if they wanted the programs to have the new accessibility features.

I understand this platform started in text-mode DOS-etc, then made a big splash in the new GUI world for a few years, because it was first to market. But then it disappeared, as new competitors beat them on all fronts: price, performance, ease of development, and built-in accessibility for little to no extra effort.
The point of this story is that accessibility is supposed to be easy for general-purpose apps, because OSes are supposed to have already done the heavy lifting. As long as programs don't go too far behind the OS's back, then they will stay in userland where the required features are provided.

The development work for accessibility then becomes a testing job, to exercise the relevant OS features, *through* yer app, to at least become aware of the various ways the app will get used by people. Also to test whether the app has any non-accessibile parts, aka defects where it escapes the safe/correct zone established by the OS. Presumably these would be small areas where someone, perhaps an add-on author, has done something in a non-standard way that ended up being too clever. (If I were to dog-food this idea then I would turn on Windows's screen reader and see what it does with command-line programs. Correction: HEAR what it does.)

Anyway, I'm not looking for a browser add-on to synthesize missing web content on the fly just to bring a web pages up to W3C html spec. I *am* looking for a commitment that says like:
- "Our browser will meet or exceed accessibility standards that existed when that section of code was created"
- "Our browser intends to keep up with more-recent accessibility standards that become generally accepted among competing browsers"
Yes it's a chicken and egg thing. In case these commitments are already true, and the project has zero relevant defects, then there's no reason to mention the concern. (I agree that saying "we have no defects in category X" is just as silly as saying "we have no bugs".) However in case there *are* any known usability troubles/defects, then it would help to give public assurance that they will be addressed.

You're right, I might be in a better position than you are to perform an "Accesibility Shootout" comparison among browsers. However part of such an effort would be contacting each browser's dev team to solicit feeback or caveats to be considered before publishing any results. I guess that's a takeaway here: is there anything about *this* browser I should know about while generating expectations about how it performs with respect to accessibility?
Off-topic:
Some guidelines say web pages should serve various versions of their content, like text-only or high-contrast colors, based on a user selection. Well I feel about that the same way that I feel about 'viewports': ya don't need to define multiple viewports if yer page design is already responsive to browser output surfaces of any shape or size. Even with printing I don't see a general need for differentiating that way.

"Web sites should show an accessibility statement." Well, no; such statements are spurious, infantilizing, annoying, and practically meaningless - just like privacy statements are. That whole category of wasted bandwidth is not quite as bad as the ridiculous "This site uses cookies" BS. Of *course* essentially all sites use cookies - that's how the modern web *works*!
I understand about forum questions that are only timesinks. But this topic must be considered by serious programs. If the topic has yes already been considered, then a few sentences saying so would suffice. (Can't believe I'm writing that, because 'statements' above.) If the topic has not already been considered, then the time investment to do so is necessary. Still, any result of considering accessibility does not need to be promoted nor publicized.

Unfort most users will never know nor care about the time investments that superior developers put in to their creations. But when it comes to standard features that a small percentage of users absolutely need as a bare minimum, that population will certainly know which products are up to snuff and which fall flat.

"We will fix any issue that anyone reports" No that's unreasonable.
"We will fix any standard thing that we break" Yes that's necessary in practice. Maybe it's assumed and understood, and thus needs no 'statement'.

TlDr:
- Ignoring specific hardware is fine, because all apps do that; awareness of specific hardware is an OS task, not a job for apps.
- Blocking built-in OS features is *not* fine, because no apps should do that; using features that the OS publishes as standard is a basic task for all apps.
I wish your answer to OP had been not like "we don't do accessibility go away" and instead more like "we do whatever accessibility your OS does; we are a general-purpose app, and such apps don't do non-standard hardware". Thus the issue is not a bug, and it's not 'by design' either. More correctly, the issue is simply out of scope - for *all* non-specialized browsers, let alone for this browser.
Apparently NVDA is Non Visual Desktop Access, a cost-free add-on for Windows that announces screen content out loud, and/or renders it to a Braille output device. I don't know enough to say how it might be better than the built-in Windows voices.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: palemoon is'nt accessible for blind users.

Unread post by Moonchild » 2021-04-14, 04:04

I'll just revise my initial statement then:

That's actually not a bug, it's by design. Pale Moon has never included support for specific accessibility hardware or software, and if you need it to interface with e.g. a Braille rule or specific accessibility APIs in the O.S. then it may not work. If you are in need of that kind of accessibility functionality, then this browser is simply not a good match for you.

Now in a more personal response to bilbo:
There was no reason at all whatsoever to go off on a tirade like that and being all aggressive about the wording or demanding I be explicitly specific. In fact, giving a technical explanation what is and is not supported is usually either completely ignored, misunderstood or in general not appreciated so I try to keep things short and to the point. It is not our task (and has never been!) to cater to specific edge cases. Yes, it means we might not be as accessible to special needs groups as other browsers, but I have never, in all this time since 2009, suggested it would be -- in fact i have been explicitly clear from the very beginning that specific accessibility features and support was never part of Pale Moon's scope, so please don't complain that I didn't mention it because that's just false. It has always been mentioned, and in fact prominently so on the home page.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Lurker_01
Fanatic
Fanatic
Posts: 122
Joined: 2015-06-12, 14:59
Location: Uruguay

Re: palemoon is'nt accessible for blind users.

Unread post by Lurker_01 » 2021-04-14, 05:12

For Bilbo47 i leave the specific quotes that are found only in Rumor control and Technical Details.

Technical Details
The following features have been disabled or removed by design:
Accessibility features. Most people don't have a need for specialized accessibility features for custom input or display devices. This cuts down on the input complexity, and increases speed, but will, obviously, not be suitable for people who need these features.
Rumor control
Moonchild wrote: Pale Moon supports full accessibility features as one can expect from a browser, like caret browsing, adaptation to high-contrast themes, etc. -- but what it does not support is specialized hardware for the severely disabled. This has been a choice since day 1 of its publication, and falls in line with another key statement about the Pale Moon browser: that it does not attempt to cater to all possible usage scenarios, but instead tries to find a sane balance between features and performance/stability. This inevitably means that deeply-complexity-impacting components that would be used by a disproportionately small portion of the users are disabled.
The browser is no less useful because of what is disabled - but it may of course not cater to specific specialized needs that specifically rely on those components and fall outside of what should be considered the scope of a web browser.

New Tobin Paradigm

Re: palemoon is'nt accessible for blind users.

Unread post by New Tobin Paradigm » 2021-04-14, 06:07

As it is open source the GUI preferences for accessibility can be uncommented or re-added (I don't know the current state in the preferences window but they did exist one upon a time) and then build with full Windows-specific accessibility enabled.

Then you can either be a full application fork or ask for special dispensation to use Pale Moon branding and also work on helping maintain UXP's lower level accessibility features we inherited from Mozilla.

Still isn't likely to change the reality of mainline Pale Moon (least not without proven long term dedication to it and maintaining those components) but someone could add to the ecosystem if it is relevant to their intrests.

But in the absence of any of that then this point goes nowhere and the status quo regarding the more complex and specialized accessibility potental would remain unchanged.

As always we are the agents OF OUR OWN salvation. The choice is yours.

tl;dr You want it, you do it. You do it well and we may help you. You do it long enough we may include it and you in. You don't do it then stop bitching.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: palemoon is'nt accessible for blind users.

Unread post by Moonchild » 2021-04-14, 07:04

Lurker_01 wrote:
2021-04-14, 05:12
found only in Rumor control and Technical Details
and on the home page a more general indicator:
purposefully excludes a number of features to strike a balance between general use, performance, and technical advancements on the Web.
And isn't all of that clear enough? The information is there on the product website. Has always been there in various forms, too.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Lurker_01
Fanatic
Fanatic
Posts: 122
Joined: 2015-06-12, 14:59
Location: Uruguay

Re: palemoon is'nt accessible for blind users.

Unread post by Lurker_01 » 2021-04-14, 14:53

Moonchild wrote:
2021-04-14, 07:04
purposefully excludes a number of features to strike a balance between general use, performance, and technical advancements on the Web.
And isn't all of that clear enough? The information is there on the product website. Has always been there in various forms, too.
As a general indicator, yes.
The fact that it is also mentioned in Technical Details is correct too (though i think general users fear/don't care about technical details (translate as implementation details) and so wont look there).
But that is IMHO and i don't know how to improve this situation.

New Tobin Paradigm

Re: palemoon is'nt accessible for blind users.

Unread post by New Tobin Paradigm » 2021-04-14, 15:19

There is still no excuse for not knowing about easily obtainable information and details. That is the biggest cause of conflict and issues for longer than I have been here.

Locked