Re: Javascript usage, accessibility and security Re: Technical question about Javascript disabled option

I'm not sure if this will be of any help, however I wrote an accessibility
tutorial regarding the use of DOM/JavaScript with the HTML <noscript>
element some years ago. Here is the Github address:

https://github.com/fmpalinkas/web-accessibility-tutorials/wiki/Replacing---%22noscript%22---with-accessible,-unobtrusive-DOM-JavaScript

Kind regards,

Frank M. Palinkas
Senior Technical Writer
Betcade, LLC
Mobile: +1 650 248 5315
Web page: https://github.com/fmpalinkas/web-accessibility-tutorials/wiki

On Fri, Oct 6, 2017 at 3:17 AM, Chaals McCathie Nevile <chaals@yandex.ru>
wrote:

> (Note, this is something of a wandering rant, not very long but very
> quickly getting away from the original topic)
>
> On Thu, 05 Oct 2017 20:05:31 +0200, David Woolley <
> forums@david-woolley.me.uk> wrote:
>
> On 05/10/17 18:34, Giacomo Petri wrote:
>>
>>> a WebAIM survey in 2014 reported that 97.6% of respondents had
>>> Javascript enabled
>>>
>>
>> The significance of this is the opposite of the obvious one.  Given the
>> vast number of sites that are unusable without Javascript enabled, it is
>> saying that there are still people who think it important not to enable it.
>>
>
> Yes - that is quite true. However the reasons for not using javascript are
> rarely related to accessibility any more, and more to do with privacy and
> security, or occasionally performance.
>
> There is some intersection of concerns - because of poor accessibility in
> browser's privacy and security interfaces there may be a stronger incentive
> to just turn off JS if you want enhanced security an privacy. As David
> notes, that means foregoing the ability to use many many common sites - a
> price some people are willing to pay in an attempt to improve their
> protection.
>
> While I think there is a strong case to be made for pushing browsers to
> enhance the accessibility of security/privacy, it is a difficult argument
> in practice and not just because browsers put accessibility at a low
> priority.
>
> The common approach over the last decade or so has been to try to ensure
> security *by default*, making it hard for users to do things that degrade
> their protection, on the assumption borne out by evidence that almost
> anything that requires users to understand security in order to protect
> themselves will effectively expose the vast majority of users. The
> consequence of this is that enhancing the ability to deal with exceptional
> cases - those who will work harder to keep more privacy or security than
> average - is a lot of work for a small segment of consumers, and will
> effectively commit developers to ongoing maintenance of the feature. That's
> already a big disincentive :(
>
> "Further complicating" the work, to ensure that it is done with
> accessibility in mind *should* be a natural process, because accessibility
> should be a straightforward requirement for any professional, but in
> practice we are a long way from that desirable state of justice and
> professionalism. And so the reality is that few people are in a position to
> do this, and many of those people are not sure *how* to do it even if they
> think it is what they should be doing. On top of that, because in many
> cases this work is done "on the margins" - for example only when developers
> have spare time to look after something - they may not have a practical way
> of finding out what they need to know.
>
> Some research and practical, *reproducible* work on enhancing the
> accessibility of user security and privacy would be a great thing. There
> are many browsers around, and some of the smaller ones (Brave, Vivaldi,
> Whale, ...) may be faster to improve in this area than those who are trying
> not to disturb their already large market share.
>
> cheers
>
> --
> Chaals is Charles McCathie Nevile
> find more at http://yandex.com
>
>