In my point of view, we need to consider the cost of maintaining a non-javascript version of all our features, in a period where we want more interactivity (using jQuery or Angular for example). Having a modern UI could be a great plus to have more users. About the screen readers, I have heard that a lot of progress have been made and that they can handle javascript now, but I need to read more about that. 2014/1/7 [email protected] <[email protected]>

+1 to officially drop support for non-javascript-enable clients (browsers).

Ideally it shouldn’t show an error (not even sure we need to go to that level) but the feature is allowed to not be present when javascript is not enabled.

Thanks -Vincent On 7 Jan 2014 at 15:29:04, Guillaume Louis-Marie Delhumeau ( [email protected]) wrote:

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

I would say it's a case by case decision (we may want to keep critical thing like editing a page/objects/class usable without javascript) with the default being to consider working without javascript an improvement and not a requirement. On Tue, Jan 7, 2014 at 3:41 PM, Caleb James DeLisle <[email protected]> wrote:

+1

Of course we always have to move cautiously and remember that DOM structure, even if js generated, can be very important to vision impaired users.

Thanks, Caleb

On 01/07/2014 03:30 PM, [email protected] wrote:

...

+1 to officially drop support for non-javascript-enable clients (browsers).

Ideally it shouldn’t show an error (not even sure we need to go to that level) but the feature is allowed to not be present when javascript is not enabled.

Thanks -Vincent On 7 Jan 2014 at 15:29:04, Guillaume Louis-Marie Delhumeau ([email protected]) wrote:

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

For information, we some key features that can not work without JS: - livetable - the top menu bar So if we decide to enable non-javascript navigation, it means we must also write non-javascript version of these features to be consistent. 2014/1/7 Caleb James DeLisle <[email protected]>

+1

Of course we always have to move cautiously and remember that DOM structure, even if js generated, can be very important to vision impaired users.

Thanks, Caleb

On 01/07/2014 03:30 PM, [email protected] wrote:

...

+1 to officially drop support for non-javascript-enable clients (browsers).

Ideally it shouldn’t show an error (not even sure we need to go to that level) but the feature is allowed to not be present when javascript is not enabled.

Thanks -Vincent On 7 Jan 2014 at 15:29:04, Guillaume Louis-Marie Delhumeau ( [email protected]) wrote:

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, FYI, there already exist an issue [1] in Jira for the problem you have mentioned, if I have properly understood. I`ve created the issue because I did not have the time, at that moment, to do it. Regarding the discussion, I`m -1 for explicitly writing code that checks the presence of JavaScript (or HTML moved to JavaScript just so that it gets added only when JS is activated, like your fix proposes). If we decide to stop supporting non-JS UIs then that is that. The UI elements will be there (links, menus, etc) but they will just not function properly. That's what everybody does and, if we do go that way, I believe it's a reasonable behavior. The web application (almost all by now) *requires* that you have JS on (which is on by default) and that if you feel like disabling it (because you probably know what you are doing) will most likely know how to re-enable it and to detect problems caused by your actions. I too feel like the effort we are putting into non-js UIs is considerable and I am not sure how appreciated or used it is by our users. Also, if enterprise is our concern, then I doubt enterprise users will start fiddling with the browser`s settings and start disabling JavaScript because they are feeling naughty :) Also, Firefox started hiding the option to disable JavaScript a while ago. It may be a bit of a developer's pride for us to see the product run without JS, but I`m not sure it`s ultimately very productive or gratifying even. +1 for dropping the backwards support, but only after we look into it a bit, see what solutions exist for problematic users and maybe provide some written guidelines on how to do it right. Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-7970 On Tue, Jan 7, 2014 at 4:47 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

For information, we have some some key features that can not work without JS right now: - livetable - the top menu bar and maybe more...

So if we decide to enable non-javascript navigation, it means we must also write non-javascript version of these features to be consistent.

2014/1/7 Caleb James DeLisle <[email protected]>

...

+1

Of course we always have to move cautiously and remember that DOM structure, even if js generated, can be very important to vision impaired users.

Thanks, Caleb

On 01/07/2014 03:30 PM, [email protected] wrote:

...

+1 to officially drop support for non-javascript-enable clients (browsers).

Ideally it shouldn’t show an error (not even sure we need to go to that level) but the feature is allowed to not be present when javascript is not enabled.

Thanks -Vincent On 7 Jan 2014 at 15:29:04, Guillaume Louis-Marie Delhumeau ( [email protected]) wrote:

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

I fully agree with Sergiu on this. Whenever I work on UI I first look for a clean and lightweight non-JavaScript solution (even if it's a partial solution). Then I see how this can be enhanced with JavaScript. The entire web page can be generated on the client side with JavaScript. So my worry is that saying "we don't need support the navigation without javascript in 2014" will lead to using JavaScript even where it's not really needed (e.g. using click listener to focus an input element in an HTML form instead of the label element with the 'for' attribute set). I think navigation should work as much as possible without JavaScript. Thanks, Marius On Wed, Jan 8, 2014 at 8:00 AM, Sergiu Dumitriu <[email protected]> wrote:

On 01/07/2014 09:28 AM, Guillaume "Louis-Marie" Delhumeau wrote:

...

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie

-1 (non binding since this isn't a vote).

But it really depends on how do we see XWiki.

If it's an enterprise application, then yes, we can drop support for accessibility.

If it's a wiki, then -1, any wiki should be all-inclusive, as a content authoring tool; but that doesn't mean that EVERYTHING must work without scripts, just that at least basic navigation and content authoring should work even from a text-based or voice-based browser.

Same answer if it's a generic web content authoring tool, not just a wiki. However, if it's a specific data entry tool with a specific target (i.e. a custom application for somebody's intranet), then it's up to the customer to decide if accessibility is a must.

If it's a web application development framework, then it doesn't necessarily have to be accessible, although it would be better (anybody can write Java code in an accessible editor, why not XWiki code?), but the resulting application (and the navigation around it) may be required to be accessible.

Anyway, asking the devs is pointless, we can write whatever kind of XWiki we want, but that doesn't mean that end users are going to be happy about it. The users are the ones that should voice their opinion.

FWIW, in the past a few XWiki users did choose XWiki because it was accessible, and XWiki SAS did sign a contract for providing and maintaining XWiki accessible, where "accessible" is defined as "passing the Dutch webrichtlijnen validation". I don't know if that contract is still in effect or not.

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

In that specific case, I agree I could have made an other decision. Actually I wanted to include the results of the other page in the current page (not only a link to that other page). Anyway, the problem is more generic that this. I agree that having at least a content editor tool accessible would be great. But we already have not this. To me, the Space Index is a mandatory feature to navigate trought the wiki and it does not work without javascript. You can not use the object editor without js neither (just try to click on the object editor link without js). So we should provide a non js solution for that too. Do we want to make that effort? 2014/1/8 Marius Dumitru Florea <[email protected]>

I've looked at what Guillaume did and adding support for non-JavaScript is just a matter of putting the right URL in the href attribute of the anchor.. We're not talking about fancy stuff here, just basic navigation which is enhanced by AJAX.

On Wed, Jan 8, 2014 at 10:46 AM, Marius Dumitru Florea <[email protected]> wrote:

...

I fully agree with Sergiu on this. Whenever I work on UI I first look for a clean and lightweight non-JavaScript solution (even if it's a partial solution). Then I see how this can be enhanced with JavaScript.

The entire web page can be generated on the client side with JavaScript. So my worry is that saying "we don't need support the navigation without javascript in 2014" will lead to using JavaScript even where it's not really needed (e.g. using click listener to focus an input element in an HTML form instead of the label element with the 'for' attribute set).

I think navigation should work as much as possible without JavaScript.

Thanks, Marius

On Wed, Jan 8, 2014 at 8:00 AM, Sergiu Dumitriu <[email protected]> wrote:

...

On 01/07/2014 09:28 AM, Guillaume "Louis-Marie" Delhumeau wrote:

...

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie

-1 (non binding since this isn't a vote).

But it really depends on how do we see XWiki.

If it's an enterprise application, then yes, we can drop support for accessibility.

If it's a wiki, then -1, any wiki should be all-inclusive, as a content authoring tool; but that doesn't mean that EVERYTHING must work without scripts, just that at least basic navigation and content authoring should work even from a text-based or voice-based browser.

Same answer if it's a generic web content authoring tool, not just a wiki. However, if it's a specific data entry tool with a specific target (i.e. a custom application for somebody's intranet), then it's up to the customer to decide if accessibility is a must.

If it's a web application development framework, then it doesn't necessarily have to be accessible, although it would be better (anybody can write Java code in an accessible editor, why not XWiki code?), but the resulting application (and the navigation around it) may be required to be accessible.

Anyway, asking the devs is pointless, we can write whatever kind of XWiki we want, but that doesn't mean that end users are going to be happy about it. The users are the ones that should voice their opinion.

FWIW, in the past a few XWiki users did choose XWiki because it was accessible, and XWiki SAS did sign a contract for providing and maintaining XWiki accessible, where "accessible" is defined as "passing the Dutch webrichtlijnen validation". I don't know if that contract is still in effect or not.

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 01/08/2014 09:14 AM, Guillaume "Louis-Marie" Delhumeau wrote:

In that specific case, I agree I could have made an other decision. Actually I wanted to include the results of the other page in the current page (not only a link to that other page).

That means that the content is accessible. A non-JS implementation doesn't have to look and behave exactly the way it does with JS, just that the content can be accessed one way or another.

Anyway, the problem is more generic that this.

I agree that having at least a content editor tool accessible would be great. But we already have not this. To me, the Space Index is a mandatory feature to navigate trought the wiki and it does not work without javascript. You can not use the object editor without js neither (just try to click on the object editor link without js).

The object editor works perfectly fine. You can get to it from the URL. You can see it in a text browser. You can see it with stylesheets disabled. The fact that the menu is not accessible is a different story, we know about it, just that nobody had the time to work on it.

So we should provide a non js solution for that too.

Do we want to make that effort?

2014/1/8 Marius Dumitru Florea <[email protected]>

...

I've looked at what Guillaume did and adding support for non-JavaScript is just a matter of putting the right URL in the href attribute of the anchor.. We're not talking about fancy stuff here, just basic navigation which is enhanced by AJAX.

On Wed, Jan 8, 2014 at 10:46 AM, Marius Dumitru Florea <[email protected]> wrote:

...

I fully agree with Sergiu on this. Whenever I work on UI I first look for a clean and lightweight non-JavaScript solution (even if it's a partial solution). Then I see how this can be enhanced with JavaScript.

The entire web page can be generated on the client side with JavaScript. So my worry is that saying "we don't need support the navigation without javascript in 2014" will lead to using JavaScript even where it's not really needed (e.g. using click listener to focus an input element in an HTML form instead of the label element with the 'for' attribute set).

I think navigation should work as much as possible without JavaScript.

Thanks, Marius

On Wed, Jan 8, 2014 at 8:00 AM, Sergiu Dumitriu <[email protected]> wrote:

...

On 01/07/2014 09:28 AM, Guillaume "Louis-Marie" Delhumeau wrote:

...

Hi devs,

In a recent pull request (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a bug reported by the accessibility validator by hiding a link if javascript is not enabled on the browser. It didn't fix the fact that the feature is unavailable without javascript, but at least the link was not there.

I did it because I have the feeling that some committers think we don't need support the navigation without javascript in 2014.

Now, it seems that we do not all agree about this.

That is why I think we should talk about this to decide what rule we should put in place for the next years.

Thanks, in advance, for your opinions.

Louis-Marie

-1 (non binding since this isn't a vote).

But it really depends on how do we see XWiki.

If it's an enterprise application, then yes, we can drop support for accessibility.

If it's a wiki, then -1, any wiki should be all-inclusive, as a content authoring tool; but that doesn't mean that EVERYTHING must work without scripts, just that at least basic navigation and content authoring should work even from a text-based or voice-based browser.

Same answer if it's a generic web content authoring tool, not just a wiki. However, if it's a specific data entry tool with a specific target (i.e. a custom application for somebody's intranet), then it's up to the customer to decide if accessibility is a must.

If it's a web application development framework, then it doesn't necessarily have to be accessible, although it would be better (anybody can write Java code in an accessible editor, why not XWiki code?), but the resulting application (and the navigation around it) may be required to be accessible.

Anyway, asking the devs is pointless, we can write whatever kind of XWiki we want, but that doesn't mean that end users are going to be happy about it. The users are the ones that should voice their opinion.

FWIW, in the past a few XWiki users did choose XWiki because it was accessible, and XWiki SAS did sign a contract for providing and maintaining XWiki accessible, where "accessible" is defined as "passing the Dutch webrichtlijnen validation". I don't know if that contract is still in effect or not.

-- Sergiu Dumitriu http://purl.org/net/sergiu