Thread:Talk:Flow Portal/Accessibility: JavaScript, screen readers, slow connections, etc./reply (9)

I agree with everything Geitost said.

I take Jorm's "may not be technically feasible" comment to mean not technically feasible with the current design. If your design cannot meet the requirements that the current system fulfils, it is a poor design. I know it feels horrible to throw away something you've poured weeks of effort into, but it's better to start afresh on something good than to keep putting effort into a poor design. And your previous effort won't be entirely wasted&#160;– you will have learnt valuable lessons that will help make the next design better.

I speak from experience here. A few years ago, my company decided to "modernise" its flagship product. (It used 80×25 text screens and was becoming unsaleable because managers who make purchasing decisions don't like the retro look. Strangely, the people actually using the software liked it!) We spent two years working on a replacement system, which was widely disliked by customers and we found it was "not technically feasible" to make the changes they wanted. So we scrapped two years of work and started again. At the time I thought this was madness; I now think this was one of the best decisions we made. Having learnt from the previous attempt we were able to produce a much better system that can do some really cool things neither of the previous systems could ever have done.

I have no objection to you using JavaScript in ways that make life easier for some editors (like the Visual Editor will), but JavaScript should never be required for any core function. If you use JavaScript for a core function, also provide a non-JS fallback mechanism (even if it is a little clunkier to use).

Like Sophus Bie, if you make the ability to edit or participate in discussions dependent on JavaScript, you will have forcibly retired me. Though perhaps a better word would be blocked&#160;– i.e. a technical restriction preventing a user from editing.