accessibility improvement

Fórumok

Boubker TAGNAOUTI, módosítva 15 év-val korábban

accessibility improvement

Regular Member Bejegyzések: 140 Csatlakozás dátuma: 2008.09.29. Legújabb bejegyzések

Hi Jorge,

Sorry for the wait... I was very busy these past few weeks. As i told you last time, I want to contribute to the setting in conformity of Liferay portal to the principal standards (WCAG, XHTML and CSS) and i'll do that in three manners :

reviewing and reporting the accessibility's issues (Level AA) for the classic theme and the liferay's core portlets.
offering solutions to fix the problems
suggesting some features to improve portal accessibility

I evaluated the 5.1.x branches version of the svn using Taw for the accessibility conformance and the w3c validators for css and markup validation.

For my first post, here is the results for the "basica" page who include theme structure, dock and navigation bar (using the community that Jorge has create for the occasion : see attached files).

Conformance Level A

As Jorge said in our last exchange "there are some
manual checks that could be debatable" and i think this first issue could be one of them.

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup

status : can not tell.
As you can see in the screenshot, the dock arrow doesn't appear : it make confusion to accede home and sign in links.

all the other tests passed successfully.

Conformance Level AA

Create documents that validate to published formal grammars.

For the markup validation it returns 9 errors:
line 2 :

the doctype XHTML 1.0 Transitional doesn't support the attribute "class" for the markup element <html>.

The class "nojs" are used to hide object that require javascript when the browser client disable it (see css_cached.jsp).

Jquery is used to remove the class attribut in the other case (see barebone_unpacked.js).

line 206 :

accessibility

Jorge Ferrer, módosítva 15 év-val korábban

RE: accessibility improvement

Liferay Legend Bejegyzések: 2871 Csatlakozás dátuma: 2006.08.31. Legújabb bejegyzések

Hi Boubker,

Thanks a lot for starting your review. I'm very excited about the significant improvements you can achieve with your help.

Regarding the color issue. Do you have any suggestion to fix it?

Regarding the other issues I think they shouldn't be too hard to fix. ¿Have you identified the files which produce the SCRIPT code and CDATA comments?

Björn Ryding, módosítva 15 év-val korábban

RE: accessibility improvement

Liferay Master Bejegyzések: 582 Csatlakozás dátuma: 2007.05.16. Legújabb bejegyzések

Jorge Ferrer:

Regarding the other issues I think they shouldn't be too hard to fix. ¿Have you identified the files which produce the SCRIPT code and CDATA comments?

Hi Jorge,

The CDATA comment is in portal_normal.vm and should be changed from // <![CDATA to // <![CDATA[.

class="lfr-script-file" is set in the VM macro js in VM_liferay.vm. This macro is used in portal_normal.vm. However, I don't know why the illegal class attribute is added to the script tag.

What about moving the nojs class from the root tag to the body tag?

Cheers,
Björn

Nate Cavanaugh, módosítva 15 év-val korábban

RE: accessibility improvement

Junior Member Bejegyzések: 94 Csatlakozás dátuma: 2006.11.27. Legújabb bejegyzések

Hi Björn,

The CDATA tag is actually changed in trunk, and has been for a few weeks. It should also be ported back to 5.1.x for EE.

As for the class attribute on script tags, that one was actually my fault. I didn't realize that the class attribute was invalid on script tags and html elements.
We may be able to remove that.

As for removing the nojs class, here are the issues:

nojs is added for accessibility and allows us to have easily hide certain elements that are written to the page but require JS.

However, moving it to the body has this issues because our convention is, and always has been:

html class attribute contains client meta data, eg. browser name, browser version, JS enabled, etc.
the body css class attribute has been reserved for theme meta data, such as the css class name for the color scheme, whether edit controls are visible, etc.

So if we move it to the body tag, we will break the existing themes, because this:


.ie .custom-color-scheme {
background: #fff;
}

will have to change to:


.ie.custom-color-scheme {
background: #fff;
}

Add to that, IE6 has certain issues with multiple selectors, so it will often misapply the styles, and it could wrongly be added the background color to the .ie element.

If we add the class attribute via JS, it's not invalid, but since we're hardcoding it, it's invalid.
But does this invalid aspect really impact accessibility whatsoever?
My argument would be that it has absolutely 0 effect.

So the other option (and you guys tell me what you think) would be to validate against our own DTD.
But sites validated with the w3c would still pull up as invalid.

I'm not sure what else to do.

In a perfect world, elements needed by JS would be created by JS, but sadly, in a page with a ton of elements being generated in random places by JS, people would experience a lot of slow down.

So in pursuit of accessibility, we've actually hampered it.

Unless there is some creative solution I'm not seeing.

(and keeping .nojs on the body, but keeping the rest on the html tag would be last on my list of possibilities, as it's incredibly inconsistent, and just adds to developer confusion).

I hope that helps.

Thanks guys,

Jorge Ferrer, módosítva 15 év-val korábban

RE: accessibility improvement

Liferay Legend Bejegyzések: 2871 Csatlakozás dátuma: 2006.08.31. Legújabb bejegyzések

Hi Nate,

Thanks for jumping in emoticon

I would try to avoid using our own DTD and stick with XHTML's official DTDs. There are several reasons for that including my secret thoughts of adding support for RDFa in the future emoticon

For that reason I'd like to suggest another pragmatic idea. What if we only move the "nojs" class to the body. That is only that specific class and not the other classes related to the browser that are added using javascript. That might be seen as slightly inconsistent but I think we can live with that and would probably solve the problem since we most probably don't use complex selectors with the nojs class, right?

In summary, with this proposal the js generated code could look like the following if js is disabled:

...

And like the following if it's enabled:

...

Thoughts?

Nate Cavanaugh, módosítva 15 év-val korábban

RE: accessibility improvement

Junior Member Bejegyzések: 94 Csatlakozás dátuma: 2006.11.27. Legújabb bejegyzések

I can totally understand about standards, but...
This will have a very real impact on people using the product, and their understanding of what's happening, and the ease of which a developer picks up our methodology.

What benefits (besides a machine giving us a gold star telling us we've gotten some good grade) is there to validating in this case?

Are we pursuing an abstract, but sacrificing developer usability?

For instance, sometimes, the css will look like:

.js .color_scheme

.nojs.color_scheme

It's just not very self-describing, and it goes against everything we've tried to do for development.

I'm thinking there has to be some other way, some way that can please both sides. I agree about pursuing validation, but I would rather spend a little time thinking about a better way than making a small compromise that hurts ease of development, but adds no real value (unless there is some tangible benefit to this that I'm not aware of).

Thanks guys,

Jorge Ferrer, módosítva 15 év-val korábban

RE: accessibility improvement

Liferay Legend Bejegyzések: 2871 Csatlakozás dátuma: 2006.08.31. Legújabb bejegyzések

Hi Nate,

I agree with the importance of ease of development, but since there is no perfect solution I think we have to be pragmatic and find a good compromise. While adding nojs to the body creates a slight inconsistency I'm pretty sure this class is not going to be used that often so in practice it won't be a big deal.

And whenever it's used it'll be by people who really care about accessibility (in the sense of W3C standards) so they'll fully understand the decision.

Note that being able to pass the automatic validation is not only important but mandated by law for websites of public administrations in Europe. So not solving this properly will be an inconvenience for people using Liferay in that market.

Jason E Shao, módosítva 15 év-val korábban

RE: accessibility improvements

Junior Member Bejegyzések: 33 Csatlakozás dátuma: 2008.08.29. Legújabb bejegyzések

I need to second the value of having the product be "accessible" out of the box. While anyone who's done real work in accessibility knows that there are many shades of grey related to maintaning the accessibility of your products and sites - there are an increasing number of industries (education, public-sector) where accessibility compliance is becoming a base-line requirement for product evaluation. It would be a shame for Liferay not to be considered in those situations because it didn't check all the boxes.

Boubker TAGNAOUTI, módosítva 15 év-val korábban

RE: accessibility improvements

Regular Member Bejegyzések: 140 Csatlakozás dátuma: 2008.09.29. Legújabb bejegyzések

Hi everyone,

I am joining Jason and Jorge to say that conforming to the standards is not a luxury but a priority which must mobilize the attention of all the community. Indeed, a great number of organizations, in particular public administrations in Europe, require an evaluation based on these automatic validations. We can try to find a solution which satisfies the various points of view (easy development and conformity of the code) provided that the benefit returns to the user (impaired or unimpaired).

To answer Jorge's question concerning color issue:
The simple solution will be to propose a more explicit title for the dock what will reduce the importance of the style on comprehension of the content. But don't worry about this issue the tool i used for the test (suppression of the color) was not suitable: there is no optical disease that completely removes all colors (either blue, or green, or red, but not all).

Here is the results concerning the dock by using another color contrast analyzer (color contrast analyzer 2.1 support by the WTA-C) which using algorithms (luminosity contrast ratio, color difference and brightness difference) suggest by the W3C to determine "color visibility".

contrast ratio: 15.5:1 (should be greater than 3:1)
color difference: 655 (should be greater than 500)
brightness difference: 220 (should be greater than 125)

For the remainder, we have in order (correct order) Deuteranope view, Shades of grey view, Inverted view, Protanope view and Tritanope view.

Björn Ryding, módosítva 15 év-val korábban

RE: accessibility improvement

Liferay Master Bejegyzések: 582 Csatlakozás dátuma: 2007.05.16. Legújabb bejegyzések

Nate Cavanaugh:

Hi Björn,

The CDATA tag is actually changed in trunk, and has been for a few weeks. It should also be ported back to 5.1.x for EE.

Hi Nate,

The CDATA tag I was referring to is not changed in trunk, see line 16:
http://lportal.svn.sourceforge.net/viewvc/lportal/portal/trunk/portal-web/docroot/html/themes/_unstyled/templates/portal_normal.vm?revision=20362&view=markup

Nate Cavanaugh, módosítva 15 év-val korábban

RE: accessibility improvement

Junior Member Bejegyzések: 94 Csatlakozás dátuma: 2006.11.27. Legújabb bejegyzések

Hi Björn,

I've gone ahead and fixed that one (I'm not sure why they were malformed, but if you run across any more, please let me know, and I'll make sure they get committed).

Okay, now as far as the nojs css class:

Upon further thinking about it, I think we can drop it completely (and still put the CSS class on the HTML tag with Javascript).

Here's how I am thinking about doing that, and please, let me know your guys opinions. I am thinking that instead of a .nojs class, I will instead style .lfr-js-required to by default position itself off of the screen.

I will then put position: static; on .js .lfr-js-required.
The benefits will be this:

Since it's not using display: none to hide it, we don't have to do a lot of guess work in showing it. The main issue with display: none; for hiding was, when you decide to show it, which do you use, display: block, or display: inline ?
Display block will show the element, but will make it block level, which will force it onto it's own line.
Display inline will also show the element, but will make it inline so that it sits on the same line as other elements.

Display block works fine for divs, tables, paragraphs, etc, but horrible for anchors, spans, strong, em, etc.

So by using positioning, it would instead throw the element far off screen whenever JS is not enabled.

Of course, neither of these solutions accounted for situations where neither JS nor CSS is enabled. Not sure how to handle that one either, short of requiring that all JS dependent HTML be created solely by JS (which is a pretty lofty goal that I don't think we'll be able to hit immediately).

So does anyone see anything wrong with doing a rule this way:

.lfr-js-required {
position: absolute;
top: -9999em;
left: -9999em;
}

.js .lfr-js-required {
position: static;
}

Thanks guys!

Alf Høgemark, módosítva 15 év-val korábban

RE: accessibility improvement

Junior Member Bejegyzések: 34 Csatlakozás dátuma: 2008.05.24. Legújabb bejegyzések

Hi

I think the file
./portal-web/docroot/html/themes/control_panel/_diffs/templates/portal_normal.vm

still has an invalid CDATA line that you should fix.

( I used the following command line on linux : find . -type f -print0 | xargs -0 grep "\[CDATA" | grep -v "\[CDATA\[" )

And when you submit that, I think you can close the following defects, since the CDATA problems are then fixed :
http://support.liferay.com/browse/LEP-7015
http://support.liferay.com/browse/LPS-294

One remaining issue, I think, is the missing encoding of ampersand in URLs, mentioned in this defect report :
http://support.liferay.com/browse/LEP-6481

Regards
Alf

Jorge Ferrer, módosítva 15 év-val korábban

RE: accessibility improvement

Liferay Legend Bejegyzések: 2871 Csatlakozás dátuma: 2006.08.31. Legújabb bejegyzések

Hi Nate,

It looks good to me.

Thanks for caring about this!!

Boubker TAGNAOUTI, módosítva 15 év-val korábban

RE: accessibility improvement

Regular Member Bejegyzések: 140 Csatlakozás dátuma: 2008.09.29. Legújabb bejegyzések

Hi Nate,

it looks good to me also.

That's a really good way to circumvent the problem.

Thanks

Nate Cavanaugh, módosítva 15 év-val korábban

RE: accessibility improvement

Junior Member Bejegyzések: 94 Csatlakozás dátuma: 2006.11.27. Legújabb bejegyzések

Hi everyone,
Just wanted to let everyone know that I have committed the changes mentioned above to trunk.

To be specific:

CDATA is now properly opened
The class attribute has been removed from script tags
The class attribute has been removed from the HTML attribute
The lfr-js-required class is now styled to position off of the page

The only thing that we're going to have trouble with is ampersands. Some pages can only be accessed with a POST, and do to this, we use Javascript to submit the url to a link.

So unobtrusively doing this wouldn't work in this case, and replacing all links that need this with form buttons and forms will break quite a bit of things (and some aren't even possible, as the links sometimes live inside of another form).

If anyone has any ideas on properly handling this, I would love to hear them emoticon

Thanks guys,

Boubker TAGNAOUTI, módosítva 15 év-val korábban

RE: accessibility improvement

Regular Member Bejegyzések: 140 Csatlakozás dátuma: 2008.09.29. Legújabb bejegyzések

Hi Nate,

Maybe i've found a solution to solve ampersand's encoding problems into javascript code. We may use %nn to encode characters. However, at no point are these decoded automatically, so we will need to decode the query part of the url using the javascript function unescape.

an example with %26 who signifies &

unescape("?p_p_id=28%26p_p_lifecycle=0%26p_p_state=maximized%26p_p_mode=view")

the output will be

?p_p_id=28&amp;p_p_lifecycle=0&amp;p_p_state=maximized&amp;p_p_mode=view

i hope it helps