[Proposal] WCAG exception: consecutive line breaks

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] WCAG exception: consecutive line breaks

Simon Urli
Hi everyone,

one of the most validation error we have with WCAG is about consecutive
line breaks: basically a <br /><br /> presents in a page.

This happens mostly in our translation pages since the linebreaks in
plain syntax are translated in <br /> tags.
Caty provided a lot of details about this error on the related issue:
https://jira.xwiki.org/browse/XWIKI-15666.

Currently we have around 140 validations failure because of this.

Different proposal have been made in order to fix it, that I will try to
sum-up here:

   A. Remove completely this validation check
   B. Add an exception for the translation pages
   C. Triggers the error only if more than 2 consecutive breaks is
encountered
   D. Create a rendering syntax dedicated to translation pages


A. Remove completely the validation check

pros:
   * the easiest one
   * apparently the rule is not checked in other accessibility test, so
its real purpose for accessibility is unclear

cons:
   * IMO this rule is useful for checking the good practice of not using
<br />

B. Add an exception for the translation pages

pros:
   * same as for A

cons:
   * ?

C. Triggers the error only if more than 2 consecutive breaks is encountered

pros:
   * ?

cons:
   * we would miss some consecutive <br /> that are used only for style
and we would catch some others in translations if we do 3 linebreaks
instead of 2. IMO it's only moving the problem

D. Create a rendering syntax dedicated to translation pages

pros:
   * remove completely the problem of consecutive <br /> in translations
   * can maybe be used to present them in another way?

cons:
   * need to develop/test/maintain a new rendering syntax

I'd personnaly vote like this:
A: +0
B: +1
C: -1
D: +0

WDYT?

Simon
--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

Adel Atallah
Hello,

On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]> wrote:

>
> Hi everyone,
>
> one of the most validation error we have with WCAG is about consecutive
> line breaks: basically a <br /><br /> presents in a page.
>
> This happens mostly in our translation pages since the linebreaks in
> plain syntax are translated in <br /> tags.
> Caty provided a lot of details about this error on the related issue:
> https://jira.xwiki.org/browse/XWIKI-15666.
>
> Currently we have around 140 validations failure because of this.
>
> Different proposal have been made in order to fix it, that I will try to
> sum-up here:
>
>    A. Remove completely this validation check

-0, I think the validation can be useful at least to keep good practices.

>    B. Add an exception for the translation pages

+1, simplest one.

>    C. Triggers the error only if more than 2 consecutive breaks is
> encountered

-1, it doesn't really makes sense to do that, it's like B. but badly done.

>    D. Create a rendering syntax dedicated to translation pages

+1, could be a good idea but might be complicated.

>
>
> A. Remove completely the validation check
>
> pros:
>    * the easiest one
>    * apparently the rule is not checked in other accessibility test, so
> its real purpose for accessibility is unclear
>
> cons:
>    * IMO this rule is useful for checking the good practice of not using
> <br />
>
> B. Add an exception for the translation pages
>
> pros:
>    * same as for A
>
> cons:
>    * ?
>
> C. Triggers the error only if more than 2 consecutive breaks is encountered
>
> pros:
>    * ?
>
> cons:
>    * we would miss some consecutive <br /> that are used only for style
> and we would catch some others in translations if we do 3 linebreaks
> instead of 2. IMO it's only moving the problem
>
> D. Create a rendering syntax dedicated to translation pages
>
> pros:
>    * remove completely the problem of consecutive <br /> in translations
>    * can maybe be used to present them in another way?
>
> cons:
>    * need to develop/test/maintain a new rendering syntax
>
> I'd personnaly vote like this:
> A: +0
> B: +1
> C: -1
> D: +0
>
> WDYT?
>
> Simon
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

Guillaume Delhumeau
A: 0
B: +1, depends on how you detect it's a translation page
C: 0
F: +0 (if we have extra time, ok)


Le mer. 21 nov. 2018 à 17:46, Adel Atallah <[hidden email]> a
écrit :

> Hello,
>
> On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]> wrote:
> >
> > Hi everyone,
> >
> > one of the most validation error we have with WCAG is about consecutive
> > line breaks: basically a <br /><br /> presents in a page.
> >
> > This happens mostly in our translation pages since the linebreaks in
> > plain syntax are translated in <br /> tags.
> > Caty provided a lot of details about this error on the related issue:
> > https://jira.xwiki.org/browse/XWIKI-15666.
> >
> > Currently we have around 140 validations failure because of this.
> >
> > Different proposal have been made in order to fix it, that I will try to
> > sum-up here:
> >
> >    A. Remove completely this validation check
>
> -0, I think the validation can be useful at least to keep good practices.
>
> >    B. Add an exception for the translation pages
>
> +1, simplest one.
>
> >    C. Triggers the error only if more than 2 consecutive breaks is
> > encountered
>
> -1, it doesn't really makes sense to do that, it's like B. but badly done.
>
> >    D. Create a rendering syntax dedicated to translation pages
>
> +1, could be a good idea but might be complicated.
>
> >
> >
> > A. Remove completely the validation check
> >
> > pros:
> >    * the easiest one
> >    * apparently the rule is not checked in other accessibility test, so
> > its real purpose for accessibility is unclear
> >
> > cons:
> >    * IMO this rule is useful for checking the good practice of not using
> > <br />
> >
> > B. Add an exception for the translation pages
> >
> > pros:
> >    * same as for A
> >
> > cons:
> >    * ?
> >
> > C. Triggers the error only if more than 2 consecutive breaks is
> encountered
> >
> > pros:
> >    * ?
> >
> > cons:
> >    * we would miss some consecutive <br /> that are used only for style
> > and we would catch some others in translations if we do 3 linebreaks
> > instead of 2. IMO it's only moving the problem
> >
> > D. Create a rendering syntax dedicated to translation pages
> >
> > pros:
> >    * remove completely the problem of consecutive <br /> in translations
> >    * can maybe be used to present them in another way?
> >
> > cons:
> >    * need to develop/test/maintain a new rendering syntax
> >
> > I'd personnaly vote like this:
> > A: +0
> > B: +1
> > C: -1
> > D: +0
> >
> > WDYT?
> >
> > Simon
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > [hidden email]
> > More about us at http://www.xwiki.com
>


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

vmassol
Administrator
In reply to this post by Adel Atallah


> On 21 Nov 2018, at 17:46, Adel Atallah <[hidden email]> wrote:
>
> Hello,
>
> On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]> wrote:
>>
>> Hi everyone,
>>
>> one of the most validation error we have with WCAG is about consecutive
>> line breaks: basically a <br /><br /> presents in a page.
>>
>> This happens mostly in our translation pages since the linebreaks in
>> plain syntax are translated in <br /> tags.
>> Caty provided a lot of details about this error on the related issue:
>> https://jira.xwiki.org/browse/XWIKI-15666.
>>
>> Currently we have around 140 validations failure because of this.
>>
>> Different proposal have been made in order to fix it, that I will try to
>> sum-up here:
>>
>>   A. Remove completely this validation check
>
> -0, I think the validation can be useful at least to keep good practices.
>
>>   B. Add an exception for the translation pages
>
> +1, simplest one.

Note that the question is not so much about being simple (we can just remove WCAG for that and it’s the simplest ;)) but about being the right thing to do for people with disabilities.

For me we have the following options:

A) We don’t think that this check is useful, ie that it brings advantages for people with disabilities and then we can remove it. No need to add exceptions.

B) We think the check is useful for people with disabilities and we should keep it, even for translations pages since I don’t see why people with disabilities shouldn’t be able to use translation pages. There are some ideas to fix this: I listed some in the jira issue and Thomas mentioned one too (it’s option D).

C) Now I’m fine if we say the following: for technical reasons it’s already hard to ensure that we pass WCAG for user pages and thus FTM we focus only on those ones and we agree that we don’t pass WCAG for developer-oriented features, with the goal of improving on that aspect in the future. And thus we disable WCAG checks on technical pages (hidden pages) for now.

Thanks
-Vincent

>
>>   C. Triggers the error only if more than 2 consecutive breaks is
>> encountered
>
> -1, it doesn't really makes sense to do that, it's like B. but badly done.
>
>>   D. Create a rendering syntax dedicated to translation pages
>
> +1, could be a good idea but might be complicated.
>
>>
>>
>> A. Remove completely the validation check
>>
>> pros:
>>   * the easiest one
>>   * apparently the rule is not checked in other accessibility test, so
>> its real purpose for accessibility is unclear
>>
>> cons:
>>   * IMO this rule is useful for checking the good practice of not using
>> <br />
>>
>> B. Add an exception for the translation pages
>>
>> pros:
>>   * same as for A
>>
>> cons:
>>   * ?
>>
>> C. Triggers the error only if more than 2 consecutive breaks is encountered
>>
>> pros:
>>   * ?
>>
>> cons:
>>   * we would miss some consecutive <br /> that are used only for style
>> and we would catch some others in translations if we do 3 linebreaks
>> instead of 2. IMO it's only moving the problem
>>
>> D. Create a rendering syntax dedicated to translation pages
>>
>> pros:
>>   * remove completely the problem of consecutive <br /> in translations
>>   * can maybe be used to present them in another way?
>>
>> cons:
>>   * need to develop/test/maintain a new rendering syntax
>>
>> I'd personnaly vote like this:
>> A: +0
>> B: +1
>> C: -1
>> D: +0
>>
>> WDYT?
>>
>> Simon
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

Thomas Mortagne
Administrator
On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol <[hidden email]> wrote:

>
>
>
> > On 21 Nov 2018, at 17:46, Adel Atallah <[hidden email]> wrote:
> >
> > Hello,
> >
> > On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]> wrote:
> >>
> >> Hi everyone,
> >>
> >> one of the most validation error we have with WCAG is about consecutive
> >> line breaks: basically a <br /><br /> presents in a page.
> >>
> >> This happens mostly in our translation pages since the linebreaks in
> >> plain syntax are translated in <br /> tags.
> >> Caty provided a lot of details about this error on the related issue:
> >> https://jira.xwiki.org/browse/XWIKI-15666.
> >>
> >> Currently we have around 140 validations failure because of this.
> >>
> >> Different proposal have been made in order to fix it, that I will try to
> >> sum-up here:
> >>
> >>   A. Remove completely this validation check
> >
> > -0, I think the validation can be useful at least to keep good practices.
> >
> >>   B. Add an exception for the translation pages
> >
> > +1, simplest one.
>
> Note that the question is not so much about being simple (we can just remove WCAG for that and it’s the simplest ;)) but about being the right thing to do for people with disabilities.
>
> For me we have the following options:
>
> A) We don’t think that this check is useful, ie that it brings advantages for people with disabilities and then we can remove it. No need to add exceptions.
>
> B) We think the check is useful for people with disabilities and we should keep it, even for translations pages since I don’t see why people with disabilities shouldn’t be able to use translation pages. There are some ideas to fix this: I listed some in the jira issue and Thomas mentioned one too (it’s option D).
>

> C) Now I’m fine if we say the following: for technical reasons it’s already hard to ensure that we pass WCAG for user pages and thus FTM we focus only on those ones and we agree that we don’t pass WCAG for developer-oriented features, with the goal of improving on that aspect in the future. And thus we disable WCAG checks on technical pages (hidden pages) for now.

Excluding hidden page for now is indeed something that would make a
lot of sense.

>
> Thanks
> -Vincent
>
> >
> >>   C. Triggers the error only if more than 2 consecutive breaks is
> >> encountered
> >
> > -1, it doesn't really makes sense to do that, it's like B. but badly done.
> >
> >>   D. Create a rendering syntax dedicated to translation pages
> >
> > +1, could be a good idea but might be complicated.
> >
> >>
> >>
> >> A. Remove completely the validation check
> >>
> >> pros:
> >>   * the easiest one
> >>   * apparently the rule is not checked in other accessibility test, so
> >> its real purpose for accessibility is unclear
> >>
> >> cons:
> >>   * IMO this rule is useful for checking the good practice of not using
> >> <br />
> >>
> >> B. Add an exception for the translation pages
> >>
> >> pros:
> >>   * same as for A
> >>
> >> cons:
> >>   * ?
> >>
> >> C. Triggers the error only if more than 2 consecutive breaks is encountered
> >>
> >> pros:
> >>   * ?
> >>
> >> cons:
> >>   * we would miss some consecutive <br /> that are used only for style
> >> and we would catch some others in translations if we do 3 linebreaks
> >> instead of 2. IMO it's only moving the problem
> >>
> >> D. Create a rendering syntax dedicated to translation pages
> >>
> >> pros:
> >>   * remove completely the problem of consecutive <br /> in translations
> >>   * can maybe be used to present them in another way?
> >>
> >> cons:
> >>   * need to develop/test/maintain a new rendering syntax
> >>
> >> I'd personnaly vote like this:
> >> A: +0
> >> B: +1
> >> C: -1
> >> D: +0
> >>
> >> WDYT?
> >>
> >> Simon
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> [hidden email]
> >> More about us at http://www.xwiki.com
>


--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

Simon Urli


On 22/11/2018 10:22, Thomas Mortagne wrote:

> On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol <[hidden email]> wrote:
>>
>>
>>
>>> On 21 Nov 2018, at 17:46, Adel Atallah <[hidden email]> wrote:
>>>
>>> Hello,
>>>
>>> On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> one of the most validation error we have with WCAG is about consecutive
>>>> line breaks: basically a <br /><br /> presents in a page.
>>>>
>>>> This happens mostly in our translation pages since the linebreaks in
>>>> plain syntax are translated in <br /> tags.
>>>> Caty provided a lot of details about this error on the related issue:
>>>> https://jira.xwiki.org/browse/XWIKI-15666.
>>>>
>>>> Currently we have around 140 validations failure because of this.
>>>>
>>>> Different proposal have been made in order to fix it, that I will try to
>>>> sum-up here:
>>>>
>>>>    A. Remove completely this validation check
>>>
>>> -0, I think the validation can be useful at least to keep good practices.
>>>
>>>>    B. Add an exception for the translation pages
>>>
>>> +1, simplest one.
>>
>> Note that the question is not so much about being simple (we can just remove WCAG for that and it’s the simplest ;)) but about being the right thing to do for people with disabilities.
>>
>> For me we have the following options:
>>
>> A) We don’t think that this check is useful, ie that it brings advantages for people with disabilities and then we can remove it. No need to add exceptions.
>>
>> B) We think the check is useful for people with disabilities and we should keep it, even for translations pages since I don’t see why people with disabilities shouldn’t be able to use translation pages. There are some ideas to fix this: I listed some in the jira issue and Thomas mentioned one too (it’s option D).
>>
>
>> C) Now I’m fine if we say the following: for technical reasons it’s already hard to ensure that we pass WCAG for user pages and thus FTM we focus only on those ones and we agree that we don’t pass WCAG for developer-oriented features, with the goal of improving on that aspect in the future. And thus we disable WCAG checks on technical pages (hidden pages) for now.
>
> Excluding hidden page for now is indeed something that would make a
> lot of sense.
>

+1 for that

>>
>> Thanks
>> -Vincent
>>
>>>
>>>>    C. Triggers the error only if more than 2 consecutive breaks is
>>>> encountered
>>>
>>> -1, it doesn't really makes sense to do that, it's like B. but badly done.
>>>
>>>>    D. Create a rendering syntax dedicated to translation pages
>>>
>>> +1, could be a good idea but might be complicated.
>>>
>>>>
>>>>
>>>> A. Remove completely the validation check
>>>>
>>>> pros:
>>>>    * the easiest one
>>>>    * apparently the rule is not checked in other accessibility test, so
>>>> its real purpose for accessibility is unclear
>>>>
>>>> cons:
>>>>    * IMO this rule is useful for checking the good practice of not using
>>>> <br />
>>>>
>>>> B. Add an exception for the translation pages
>>>>
>>>> pros:
>>>>    * same as for A
>>>>
>>>> cons:
>>>>    * ?
>>>>
>>>> C. Triggers the error only if more than 2 consecutive breaks is encountered
>>>>
>>>> pros:
>>>>    * ?
>>>>
>>>> cons:
>>>>    * we would miss some consecutive <br /> that are used only for style
>>>> and we would catch some others in translations if we do 3 linebreaks
>>>> instead of 2. IMO it's only moving the problem
>>>>
>>>> D. Create a rendering syntax dedicated to translation pages
>>>>
>>>> pros:
>>>>    * remove completely the problem of consecutive <br /> in translations
>>>>    * can maybe be used to present them in another way?
>>>>
>>>> cons:
>>>>    * need to develop/test/maintain a new rendering syntax
>>>>
>>>> I'd personnaly vote like this:
>>>> A: +0
>>>> B: +1
>>>> C: -1
>>>> D: +0
>>>>
>>>> WDYT?
>>>>
>>>> Simon
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>
>
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

Marius Dumitru Florea
In reply to this post by Thomas Mortagne
On Thu, Nov 22, 2018 at 11:22 AM Thomas Mortagne <[hidden email]>
wrote:

> On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol <[hidden email]> wrote:
> >
> >
> >
> > > On 21 Nov 2018, at 17:46, Adel Atallah <[hidden email]> wrote:
> > >
> > > Hello,
> > >
> > > On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]>
> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> one of the most validation error we have with WCAG is about
> consecutive
> > >> line breaks: basically a <br /><br /> presents in a page.
> > >>
> > >> This happens mostly in our translation pages since the linebreaks in
> > >> plain syntax are translated in <br /> tags.
> > >> Caty provided a lot of details about this error on the related issue:
> > >> https://jira.xwiki.org/browse/XWIKI-15666.
> > >>
> > >> Currently we have around 140 validations failure because of this.
> > >>
> > >> Different proposal have been made in order to fix it, that I will try
> to
> > >> sum-up here:
> > >>
> > >>   A. Remove completely this validation check
> > >
> > > -0, I think the validation can be useful at least to keep good
> practices.
> > >
> > >>   B. Add an exception for the translation pages
> > >
> > > +1, simplest one.
> >
> > Note that the question is not so much about being simple (we can just
> remove WCAG for that and it’s the simplest ;)) but about being the right
> thing to do for people with disabilities.
> >
> > For me we have the following options:
> >
> > A) We don’t think that this check is useful, ie that it brings
> advantages for people with disabilities and then we can remove it. No need
> to add exceptions.
> >
> > B) We think the check is useful for people with disabilities and we
> should keep it, even for translations pages since I don’t see why people
> with disabilities shouldn’t be able to use translation pages. There are
> some ideas to fix this: I listed some in the jira issue and Thomas
> mentioned one too (it’s option D).
> >
>
> > C) Now I’m fine if we say the following: for technical reasons it’s
> already hard to ensure that we pass WCAG for user pages and thus FTM we
> focus only on those ones and we agree that we don’t pass WCAG for
> developer-oriented features, with the goal of improving on that aspect in
> the future. And thus we disable WCAG checks on technical pages (hidden
> pages) for now.
>
>

> Excluding hidden page for now is indeed something that would make a
> lot of sense.
>

I agree. The issue is that we can have hidden pages that:

* are not displayed by default (I'm thinking panels)
* are included / displayed dynamically with JavaScript so they won't appear
in the HTML downloaded by our WCAG tests (I'm thinking of async panels and
modals for instance)

So they won't be covered.


>
> >
> > Thanks
> > -Vincent
> >
> > >
> > >>   C. Triggers the error only if more than 2 consecutive breaks is
> > >> encountered
> > >
> > > -1, it doesn't really makes sense to do that, it's like B. but badly
> done.
> > >
> > >>   D. Create a rendering syntax dedicated to translation pages
> > >
> > > +1, could be a good idea but might be complicated.
> > >
> > >>
> > >>
> > >> A. Remove completely the validation check
> > >>
> > >> pros:
> > >>   * the easiest one
> > >>   * apparently the rule is not checked in other accessibility test, so
> > >> its real purpose for accessibility is unclear
> > >>
> > >> cons:
> > >>   * IMO this rule is useful for checking the good practice of not
> using
> > >> <br />
> > >>
> > >> B. Add an exception for the translation pages
> > >>
> > >> pros:
> > >>   * same as for A
> > >>
> > >> cons:
> > >>   * ?
> > >>
> > >> C. Triggers the error only if more than 2 consecutive breaks is
> encountered
> > >>
> > >> pros:
> > >>   * ?
> > >>
> > >> cons:
> > >>   * we would miss some consecutive <br /> that are used only for style
> > >> and we would catch some others in translations if we do 3 linebreaks
> > >> instead of 2. IMO it's only moving the problem
> > >>
> > >> D. Create a rendering syntax dedicated to translation pages
> > >>
> > >> pros:
> > >>   * remove completely the problem of consecutive <br /> in
> translations
> > >>   * can maybe be used to present them in another way?
> > >>
> > >> cons:
> > >>   * need to develop/test/maintain a new rendering syntax
> > >>
> > >> I'd personnaly vote like this:
> > >> A: +0
> > >> B: +1
> > >> C: -1
> > >> D: +0
> > >>
> > >> WDYT?
> > >>
> > >> Simon
> > >> --
> > >> Simon Urli
> > >> Software Engineer at XWiki SAS
> > >> [hidden email]
> > >> More about us at http://www.xwiki.com
> >
>
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] WCAG exception: consecutive line breaks

Thomas Mortagne
Administrator
On Mon, Nov 26, 2018 at 12:00 PM Marius Dumitru Florea
<[hidden email]> wrote:

>
> On Thu, Nov 22, 2018 at 11:22 AM Thomas Mortagne <[hidden email]>
> wrote:
>
> > On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol <[hidden email]> wrote:
> > >
> > >
> > >
> > > > On 21 Nov 2018, at 17:46, Adel Atallah <[hidden email]> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Wed, Nov 21, 2018 at 5:36 PM Simon Urli <[hidden email]>
> > wrote:
> > > >>
> > > >> Hi everyone,
> > > >>
> > > >> one of the most validation error we have with WCAG is about
> > consecutive
> > > >> line breaks: basically a <br /><br /> presents in a page.
> > > >>
> > > >> This happens mostly in our translation pages since the linebreaks in
> > > >> plain syntax are translated in <br /> tags.
> > > >> Caty provided a lot of details about this error on the related issue:
> > > >> https://jira.xwiki.org/browse/XWIKI-15666.
> > > >>
> > > >> Currently we have around 140 validations failure because of this.
> > > >>
> > > >> Different proposal have been made in order to fix it, that I will try
> > to
> > > >> sum-up here:
> > > >>
> > > >>   A. Remove completely this validation check
> > > >
> > > > -0, I think the validation can be useful at least to keep good
> > practices.
> > > >
> > > >>   B. Add an exception for the translation pages
> > > >
> > > > +1, simplest one.
> > >
> > > Note that the question is not so much about being simple (we can just
> > remove WCAG for that and it’s the simplest ;)) but about being the right
> > thing to do for people with disabilities.
> > >
> > > For me we have the following options:
> > >
> > > A) We don’t think that this check is useful, ie that it brings
> > advantages for people with disabilities and then we can remove it. No need
> > to add exceptions.
> > >
> > > B) We think the check is useful for people with disabilities and we
> > should keep it, even for translations pages since I don’t see why people
> > with disabilities shouldn’t be able to use translation pages. There are
> > some ideas to fix this: I listed some in the jira issue and Thomas
> > mentioned one too (it’s option D).
> > >
> >
> > > C) Now I’m fine if we say the following: for technical reasons it’s
> > already hard to ensure that we pass WCAG for user pages and thus FTM we
> > focus only on those ones and we agree that we don’t pass WCAG for
> > developer-oriented features, with the goal of improving on that aspect in
> > the future. And thus we disable WCAG checks on technical pages (hidden
> > pages) for now.
> >
> >
>
> > Excluding hidden page for now is indeed something that would make a
> > lot of sense.
> >
>
> I agree. The issue is that we can have hidden pages that:
>
> * are not displayed by default (I'm thinking panels)

Yes, we just need to have a filter a little bit more advanced than
"hidden=false". We could imagine a white list of xclasses (which would
have priority over "hidden=false" filter).

Now for the specific panels use case we actually have a place where
they are all displayed and validated all at once: the administration.

> * are included / displayed dynamically with JavaScript so they won't appear
> in the HTML downloaded by our WCAG tests (I'm thinking of async panels and
> modals for instance)

Validating DOM generated in javascript is indeed a problem we already
have. Now for the few cases which are actually wiki pages included
asynchronously and which don't fit in a generic xclass based filter we
could add them trough the existing URL list property.

About async panels, most of them are also cached which means they are
really asyn only when loading the first page (when the framework find
a cached content is return it instead of putting an async
placeholder).

>
> So they won't be covered.
>
>
> >
> > >
> > > Thanks
> > > -Vincent
> > >
> > > >
> > > >>   C. Triggers the error only if more than 2 consecutive breaks is
> > > >> encountered
> > > >
> > > > -1, it doesn't really makes sense to do that, it's like B. but badly
> > done.
> > > >
> > > >>   D. Create a rendering syntax dedicated to translation pages
> > > >
> > > > +1, could be a good idea but might be complicated.
> > > >
> > > >>
> > > >>
> > > >> A. Remove completely the validation check
> > > >>
> > > >> pros:
> > > >>   * the easiest one
> > > >>   * apparently the rule is not checked in other accessibility test, so
> > > >> its real purpose for accessibility is unclear
> > > >>
> > > >> cons:
> > > >>   * IMO this rule is useful for checking the good practice of not
> > using
> > > >> <br />
> > > >>
> > > >> B. Add an exception for the translation pages
> > > >>
> > > >> pros:
> > > >>   * same as for A
> > > >>
> > > >> cons:
> > > >>   * ?
> > > >>
> > > >> C. Triggers the error only if more than 2 consecutive breaks is
> > encountered
> > > >>
> > > >> pros:
> > > >>   * ?
> > > >>
> > > >> cons:
> > > >>   * we would miss some consecutive <br /> that are used only for style
> > > >> and we would catch some others in translations if we do 3 linebreaks
> > > >> instead of 2. IMO it's only moving the problem
> > > >>
> > > >> D. Create a rendering syntax dedicated to translation pages
> > > >>
> > > >> pros:
> > > >>   * remove completely the problem of consecutive <br /> in
> > translations
> > > >>   * can maybe be used to present them in another way?
> > > >>
> > > >> cons:
> > > >>   * need to develop/test/maintain a new rendering syntax
> > > >>
> > > >> I'd personnaly vote like this:
> > > >> A: +0
> > > >> B: +1
> > > >> C: -1
> > > >> D: +0
> > > >>
> > > >> WDYT?
> > > >>
> > > >> Simon
> > > >> --
> > > >> Simon Urli
> > > >> Software Engineer at XWiki SAS
> > > >> [hidden email]
> > > >> More about us at http://www.xwiki.com
> > >
> >
> >
> > --
> > Thomas Mortagne
> >



--
Thomas Mortagne