Accessibility solutions within Joomla!

[absalom]

Currently rotating through this site is the attached ad.

Now it says these professional CSS powered templates are accessible..

So let's see if they can follow through on their claims:

• 508,
• WAI A.

These test remain a very basic mechanical way of ascertaing whether or not there is some adherence to web accessibility standards. These tests are not the end of accessibility testing and conformance, but more a guide to where standards need to begin. Having such designers claim accessibility benefits for their work might seem a good marketing practice, but if they can't even conform to the basic mechanical tests (which are the bottom rung of accessibility and usabilty work to do with websites), they reflect poorly on the wider design industry as people will not be getting what they paid for. And it's the experience at the end of the day that matters to the people we are servicing and supporting.

So what matters more in Joomla ? The sales pitch or the awful truth ?

[brad]

I suggest you contact Rockettheme.com directly.

So what matters more in Joomla ? The sales pitch or the awful truth ?

Just because Andy is also a member of the Core Team, does not mean 'Joomla' approves/supports his commercial products or advertising. Joomla is not pitching any sales to you, Rockettheme is, you really need to take it up with them.
People do not pay Joomla for Rockettheme products...

[absalom]

I suggest you contact Rockettheme.com directly.

I think they already know this.

Just because Andy is also a member of the Core Team, does not mean 'Joomla' approves/supports his commercial products or advertising. Joomla is not pitching any sales to you, Rockettheme is, you really need to take it up with them.
People do not pay Joomla for Rockettheme products...

Not even implying anything of the sort, Brad. My point was: what are we dealing with when we enter the Joomla commercial marketplace? Can the very designers who market here face criticism or not ? Oh, and.. does Joomla itself have any standards for advertising on it's site?

[manuman]

I find the whole accessability/standards debate to be one that seems to be falling in upon itself. Even the self appointed guru's on the subject have on numerous occasions in the past failed to actually agree on even the most basic of questions regarding what is the correct way to do things in an accessable way.

I noticed rockettheme is currently #1 on Silktide, a site you yourself utilise as a measure of your own site and one that also tests accessability. You may also notice that whilst rockettheme gets 10/10 for accessability your own site gets a mere 9.7. (Is that whats meant by the "pot calling the kettle black" I wonder?)

See here...

Yours :: http://www.silktide.com/index.php?node= ... bsalom.biz

Rockettheme :: http://www.silktide.com/index.php?node= ... &objectid=

For both sites it states that ...

All webpages were found to be fully compliant with the W3C Web Content Accessibility Guidelines, and therefore likely not in violation of the British Disability Discrimination Act. Pages make proper use of the latest XHTML standards.

I would suggest that people including yourself and Andy who are at least trying to accomplish accessibility all be applauded for it. I certainly think your original post was at best unfair to both Rocket theme and Joomla! and at worst a bit of sour grapes at being piped on Silktide.

I really hope to see more positive debate about this very serious subject rather than the barbs and accusations.

Cheers
Shayne

[absalom]

I find the whole accessability/standards debate to be one that seems to be falling in upon itself. Even the self appointed guru's on the subject have on numerous occasions in the past failed to actually agree on even the most basic of questions regarding what is the correct way to do things in an accessable way.

Such as ? Your comments seem unfounded, and the best way to resolve this is to demonstrate something verbatim as to what the "most basic of questions" can portray disagreement.

I noticed rockettheme is currently #1 on Silktide, a site you yourself utilise as a measure of your own site and one that also tests accessability. You may also notice that whilst rockettheme gets 10/10 for accessability your own site gets a mere 9.7. (Is that whats meant by the "pot calling the kettle black" I wonder?)

I would suggest you look at the the Silktide discussion with Compass for points of reference on this. Most of the people "in the know" for U&A recognise mechanical scripts / validation can go south / break, or provide false positives that should be analysed using manual, human interaction. Silktide, in this respect, is wandering south (Priority 2 DDA UK requires full CSS-only design, if you care to check). I also talked about this phenomena in my initial post.

I would suggest that people including yourself and Andy who are at least trying to accomplish accessibility all be applauded for it.

So why does Joomla itself lag so far behind ? If the core isn't listening to U&A, why are we here?

I certainly think your original post was at best unfair to both Rocket theme and Joomla! and at worst a bit of sour grapes at being piped on Silktide.

Is it unfair to see if Joomla has any standards for advertising on its site ?

Is it unfair to see if designers can face criticism or is this industry so vain it cannot face the same kudos and credibility standards afforded to architectural and landscape designers (who have a much wider and longer history than we do, so the same rules that apply to them also may apply to us) ?

And just to keep the peanut gallery happy: This has absolutely nothing to do with Silktide.

[manuman]

Hi again...

In reference to the first... I can't publically display them as that would be to display private forum conversations. They are in a forum you have access to, so before you go down that road I suggest you check them out

You've just justified my second point yourself... there are currently upteen various standards by which one can judge accessability. You have listed several yourself. The whole debate globally is still stuck in a subjective loop when objectiveness is desperately required.

So why does Joomla itself lag so far behind ? If the core isn't listening to U&A, why are we here?

Joomla! lags in several area's.. my own personal gripe is permissions. But quite rightly it was decided to fix the hull before adding a deck. I noticed in another thread today your advocating introducing accessability changes into 1.0.12. This in turn implies you consider accessability to be more important than stability which is what the minor releases are for, as to start introducing accessability changes at into a stablilty release would certainly push out its release. Do you really think this would be best for Joomla!

Is it unfair to see if Joomla has any standards for advertising on its site ?

Is it unfair to see if designers can face criticism or is this industry so vain it cannot face the same kudos and credibility standards afforded to architectural and landscape designers (who have a much wider and longer history than we do, so the same rules that apply to them also may apply to us) ?

Again... if we are to do as you suggest and hold advertisements accountable against standards... which standards, and who's interpretation of those standards? To simply point to a bunch of tests that you yourself acknowledge are insufficient to use as a definitive guide doesn't really help.

PS... peanuts very happy, thanks for your concen.

[absalom]

In reference to the first... I can't publically display them as that would be to display private forum conversations. They are in a forum you have access to, so before you go down that road I suggest you check them out

I thought you had access to that same forum ? 

You've just justified my second point yourself... there are currently upteen various standards by which one can judge accessability. You have listed several yourself. The whole debate globally is still stuck in a subjective loop when objectiveness is desperately required.

Case in point for subjectivity: Silktide.. The shiny red button says one thing whereas numerous other mechanical tests say another.

Human interaction always determines objectivity in this respect. All mechanical tests do is act like dumb waiters for web designers in this respect.

Joomla! lags in several area's.. my own personal gripe is permissions. But quite rightly it was decided to fix the hull before adding a deck. I noticed in another thread today your advocating introducing accessability changes into 1.0.12. This in turn implies you consider accessability to be more important than stability which is what the minor releases are for, as to start introducing accessability changes at into a stablilty release would certainly push out its release. Do you really think this would be best for Joomla!

So do we both agree the hull is stable ?

And there is sound, justifiable reason behind what I'm advocating. .12 is meant to be the absolute final release of the 1.0.x line, before it becomes grandfathered thanks to the 1.5 development . Instead of making it a small insignificant blip on the radar before 1.5 arrives, at least make it go out in style.  For some people will not choose to always go to the absolute latest release. J! will probably still have a large userbase on 1.0.x for a while (esp. since I know people who are still running Mambo 4.5.0) and to allow some significant value adds in the final release will guarantee both take up, and increase the expectations of what 1.5 can deliver (i.e if 1.0.x has , how much better will 1.5 be?)

The rewards in this respect outweigh the risks, and the core would buy themselves significant leverage if they pulled this off. The only potential reason I can see you counterpointing me with is it will increase release time, and since we've been churning through releases cycles since the first release of 1.0.0, why not take a breather, step outside the box, and leave a good feeling in people with an "eye-candy" style version of .12 instead of just another boring "bug-fix" release ? Respond, don't react to the bugs..The bugs can be fixed anyway, it's what you do with everything else that matters..

Again... if we are to do as you suggest and hold advertisements accountable against standards... which standards, and who's interpretation of those standards? To simply point to a bunch of tests that you yourself acknowledge are insufficient to use as a definitive guide doesn't really help.

That I'm unsure of. Perhaps looking at mainstream commercial media and the advertising standards governing them might be an appropriate path, as Joomla is international in scope, and therefore the international laws coverning media standards should apply (UN, maybe?)

[RobS]

So do we both agree the hull is stable ?

And there is sound, justifiable reason behind what I'm advocating. .12 is meant to be the absolute final release of the 1.0.x line, before it becomes grandfathered thanks to the 1.5 development . Instead of making it a small insignificant blip on the radar before 1.5 arrives, at least make it go out in style.  For some people will not choose to always go to the absolute latest release. J! will probably still have a large userbase on 1.0.x for a while (esp. since I know people who are still running Mambo 4.5.0) and to allow some significant value adds in the final release will guarantee both take up, and increase the expectations of what 1.5 can deliver (i.e if 1.0.x has , how much better will 1.5 be?)

The rewards in this respect outweigh the risks, and the core would buy themselves significant leverage if they pulled this off. The only potential reason I can see you counterpointing me with is it will increase release time, and since we've been churning through releases cycles since the first release of 1.0.0, why not take a breather, step outside the box, and leave a good feeling in people with an "eye-candy" style version of .12 instead of just another boring "bug-fix" release ? Respond, don't react to the bugs..The bugs can be fixed anyway, it's what you do with everything else that matters..

This seems to be a very strange proposition coming from someone who obviously has such high regard for standards.  Do project standards and protocols not matter?  Should it not matter that we have a project rule that says no new features should be implemented in a maintenance release?  In my opinion it matters very much and experience has proven this point time and again.  If you look at the 1.0.x series you will notice a scary trend; whenever new features were released, a massive amount of new bugs were created.  This further caused an additional release to be made to address the bugs created from the last version.  This is obviously a poor practice to maintain and why we have been revamping that system.  We want to create the most stable product that we can and in order to do that, we cannot and will not introduce new features into maintenance releases anymore.

So, again, we will not be adding "eye candy" to 1.0.12 because contrary to some peoples' belief, that is not what is important.  I think it is more important that Joomla! actually works like it is supposed to and I know that the users agree.  I am not interested in a Ferrari paint job, I am interested in the whole Ferrari.  But, we can't paint the Ferrari until we have the motor and the brakes and chassis and the body panels and on and on.  And truthfully, we aren't there yet.

So why does Joomla itself lag so far behind ? If the core isn't listening to U&A, why are we here?

Again, you have to get the chassis built before you can install the really cool leather seats.  We have come a long long way, have you looked at 1.5 lately?  Have you looked at the way the frontend components are built?  The way that the logic is completely separate from the presentation?  Aren't these things that you guys have been asking for?  We are listening, you just don't see it all yet because it all goes into 1.5 because 1.0 is supposed to be stable which means it will not get these snazzy new features added to it.

[manuman]

So do we both agree the hull is stable ?

Not quite, its whats the devs are doing at the moment (Joomla! 1.5).

You are correct when you say my point is the release time. If 1.0.12 is for stability and/or security patchs (which it is), to hold off while a new feature is added would be irresponsible. There are already community people biting the devs heals as they feel things take to long, your suggesting we do something that would push the next release back weeks if not months.

In regards to media/advertsing laws, the general area that would cover what you have brough up is what you and I would know (as we are both in Australia) as Truth in Advertising, it exists in most territories under various names. In this regard the advertisor may not make false claims and the product/serveice must perform as "advertised".

Rocket Themes advetisiment states that they make accessible templates. You test was of the Rocket Theme site, not their templates. I await your testing of their actual templates devoid of any invalid code coming from a source other than the actual template. Also... it doesn't mean ALL their templates need be compliant, only that they DO provide them. That would be your test of truth in advertising.

Have fun 

Cheers
Shayne

[absalom]

This seems to be a very strange proposition coming from someone who obviously has such high regard for standards.  Do project standards and protocols not matter?  Should it not matter that we have a project rule that says no new features should be implemented in a maintenance release?  In my opinion it matters very much and experience has proven this point time and again.  If you look at the 1.0.x series you will notice a scary trend; whenever new features were released, a massive amount of new bugs were created.  This further caused an additional release to be made to address the bugs created from the last version.  This is obviously a poor practice to maintain and why we have been revamping that system.  We want to create the most stable product that we can and in order to do that, we cannot and will not introduce new features into maintenance releases anymore.

So why should the project standards not resolve outstanding criticisms that have been hanging over the project for the last 2 to 3 years ?

I deal with commercial vendors providers and to simply state because you, as Q&T have a policy or protocol of not even attempting to fix the significant areas of architecture that fail, instead just focussing on the "bug-fixes", you place yourself into a product cycle that does not end up delivering what clients want. It may damned well deliver what you want, but that's you. You're not the client.

Furthermore, who ratified this policy and protocol in such a way that U&A has next to no voice to significantly direct and shape the CMS till 1.6 or 1.7 vapourware ?

So, again, we will not be adding "eye candy" to 1.0.12 because contrary to some peoples' belief, that is not what is important.  I think it is more important that Joomla! actually works like it is supposed to and I know that the users agree.

And does the work carried out by the various accessibility guys (e.g. my own Project Orange for Mambo, RunDigital's accessibility patches, a8e, 55 Thinking's work, Compass Design, Vavroom's direction whilst he was part of the J! core) not work like it's supposed to ? Think about what you're saying, Rob..  You're coming across to me as saying you'll only do the "work" that you think "works", not those things that have been tried and tested and not found wanting..

I am not interested in a Ferrari paint job, I am interested in the whole Ferrari.  But, we can't paint the Ferrari until we have the motor and the brakes and chassis and the body panels and on and on.  And truthfully, we aren't there yet.

I know full well the reasons why we aren't there yet. Some remain political, some remain organisational. None of the reasons are technological.. We can build the basic Ferrari now. We can supercharge it in the major design revision. We don't have to wait 3 years for a V12 inline triple supercharged Ferrari to be built. How do I know this ? We've been churning out accessibility hack after accessibility hack since 4.5.0 days, complete with the anguish and heartache of the version control issues. The only reason we keep on having these version control issues is that the core, for reasons unknown, has refused to even adopt what has been existing within the community, both at a technological level and an organisational level, for the last 3 years as a working standard.

Again, you have to get the chassis built before you can install the really cool leather seats.  We have come a long long way, have you looked at 1.5 lately?  Have you looked at the way the frontend components are built?  The way that the logic is completely separate from the presentation?  Aren't these things that you guys have been asking for?  We are listening, you just don't see it all yet because it all goes into 1.5 because 1.0 is supposed to be stable which means it will not get these snazzy new features added to it.

Why not ?

The solutions and answers you are giving me (and the rest of the wider J! userbase) do not remain asethetically or functionally beautiful. All you have is some vacous policy or protocol you can't reference, can't tell me why it was ratified, can't tell me how much voice the people who actually know the biz (U&A) have, let alone who controls and revises this protocol.

We've been advocating for this to the core for 3 years now. How many more vacous promises will the core recind on, like they recinded on pT, WCAG 1.0 compliance in J 1.5 and other stuff ?

The retrofits needed has been available for a while (at least 2 years). Please explain to the wider community why this retrofit has been stalled and rejected in lieu of other "work"

[RobS]

This is going to be a long post, I apologize in advance for that.

I admit that I do not have a firm grasp of the changes required to make Joomla! as accessible as desired.  I assume(d) that it requires significant reworking but I have no real reason for this assumption.  It was that assumption that lead to the rigidity of my earlier response about what will and will not be implemented for 1.0.12.  Truthfully, my response was not entirely accurate either as we have implemented several small fixes for accessability bugs that were reported on the tracker.  But the main goals of 1.0.12 are to deal with the problems that were created by 1.0.11, to address as many of the outstanding known "bugs" as possible, and to do a security audit to avoid any other potential issues from popping up.  I firmly believe that these are important things to accomplish but these tasks are very large and time consuming which are stretching the limits of our resources as far as development and testing.  At this point, with the significant issues introduced by 1.0.11 and the very serious concerns about security, I do not think accessability changes are as high of a priority.  That does not mean they are out, it just means that we cannot focus much resources toward them.

This seems to be a very strange proposition coming from someone who obviously has such high regard for standards.  Do project standards and protocols not matter?  Should it not matter that we have a project rule that says no new features should be implemented in a maintenance release?  In my opinion it matters very much and experience has proven this point time and again.  If you look at the 1.0.x series you will notice a scary trend; whenever new features were released, a massive amount of new bugs were created.  This further caused an additional release to be made to address the bugs created from the last version.  This is obviously a poor practice to maintain and why we have been revamping that system.  We want to create the most stable product that we can and in order to do that, we cannot and will not introduce new features into maintenance releases anymore.

So why should the project standards not resolve outstanding criticisms that have been hanging over the project for the last 2 to 3 years ?

I deal with commercial vendors providers and to simply state because you, as Q&T have a policy or protocol of not even attempting to fix the significant areas of architecture that fail, instead just focussing on the "bug-fixes", you place yourself into a product cycle that does not end up delivering what clients want. It may damned well deliver what you want, but that's you. You're not the client.

Furthermore, who ratified this policy and protocol in such a way that U&A has next to no voice to significantly direct and shape the CMS till 1.6 or 1.7 vapourware ?

Well, in general, I think this is all part of a great project communication issue that we are trying to fix but still have a long way to go.  To begin, you refer to accessability issues as "criticisms".  The Q&T team which probably should attempt to address such criticisms in the name of Quality is unable to due to lack of human resources.  We are in fact, so poorly equipped that historically we could not even test a significant portion of the code base and had no idea what was being tested due to organizational issues.  It was generally deemed to be more important to address the Testing and "bug" issues than to address the Quality issues so Testing has always received substantially more time.  While I cannot speak for much of the past of the project as I am fairly new to it and very new as the Q&T coordinator I can speak of the current situation.  These accessability issues being thought of as criticisms is not helping to further your goals.  It would be more beneficial if you said, look, this code right here does not meet such and such standard, it is a bug.  Then, open up a bug report on the tracker so that we know there is a bug with that line that results in non-standard-compliant output for example.  This puts it in our field of vision and gives us an opportunity to look at it and see if we can do something about it.

There is only so much that we can handle right now due to people being inactive, on vacation, AWOL, etc.  Q&T has always and continues to be severely limited in terms of resources and there is a lot of stuff out there that needs attention and testing.  However, I have made attempts to deal with the issues that I was informed about.  Since 1.0.11 was realeased, we have gone through the entire bug tracker and eliminated most of the issues that were there, including several accessability and standard-compliance issues.  They were taken care of because I was aware of them and I thought they were worth fixing.  If I am not aware of a issue I cannot be expected to fix it.  Additionally, I can not speak of the people before me in Q&T or Development as I was not "in the know" with the reasoning for why these things have not been addressed to date.

So, again, we will not be adding "eye candy" to 1.0.12 because contrary to some peoples' belief, that is not what is important.  I think it is more important that Joomla! actually works like it is supposed to and I know that the users agree.

And does the work carried out by the various accessibility guys (e.g. my own Project Orange for Mambo, RunDigital's accessibility patches, a8e, 55 Thinking's work, Compass Design, Vavroom's direction whilst he was part of the J! core) not work like it's supposed to ? Think about what you're saying, Rob..  You're coming across to me as saying you'll only do the "work" that you think "works", not those things that have been tried and tested and not found wanting..

Perhaps I was too general with "works," I mean users want the features that they have come to enjoy and depend on like for example, being able to log in or being able to edit mambots to work and continue to work.  I am in no way saying that what the accessability projects are doing or have done does not work.  My point was only that when we release a maintenance or security release, it is very important that nothing breaks.  That main mission behind Q&T is testing things to make sure they work correctly OR as they have in the past it is has been deemed reasonably acceptable behavior.  As I said before and have no problems with saying again, we have very limited resources and testing these things takes a lot of time.  I would actually love to see some of the changes that the accessability projects suggest, I would absolutely consider implementing some of those changes.  Trust me, I have nothing against accessability, I am not trying to impede your work or make things difficult for you but this is not something that I follow much of on my own so I need you guys in D&A to bring it to the attention of Q&T and then we can start making some progress on these things.

I am not interested in a Ferrari paint job, I am interested in the whole Ferrari.  But, we can't paint the Ferrari until we have the motor and the brakes and chassis and the body panels and on and on.  And truthfully, we aren't there yet.

I know full well the reasons why we aren't there yet. Some remain political, some remain organisational. None of the reasons are technological.. We can build the basic Ferrari now. We can supercharge it in the major design revision. We don't have to wait 3 years for a V12 inline triple supercharged Ferrari to be built. How do I know this ? We've been churning out accessibility hack after accessibility hack since 4.5.0 days, complete with the anguish and heartache of the version control issues. The only reason we keep on having these version control issues is that the core, for reasons unknown, has refused to even adopt what has been existing within the community, both at a technological level and an organisational level, for the last 3 years as a working standard.

Again, I can only suspect this is part of the greater communication issues of the project or a matter of scope for the hacks.  If one of the accessability hacks is too extensive, meaning, it requires significant changes to core architecture or standard (and relied upon) behavior (even if incorrect) it would not be implemented in a maintenace release.

Again, you have to get the chassis built before you can install the really cool leather seats.  We have come a long long way, have you looked at 1.5 lately?  Have you looked at the way the frontend components are built?  The way that the logic is completely separate from the presentation?  Aren't these things that you guys have been asking for?  We are listening, you just don't see it all yet because it all goes into 1.5 because 1.0 is supposed to be stable which means it will not get these snazzy new features added to it.

Why not ?

The solutions and answers you are giving me (and the rest of the wider J! userbase) do not remain asethetically or functionally beautiful. All you have is some vacous policy or protocol you can't reference, can't tell me why it was ratified, can't tell me how much voice the people who actually know the biz (U&A) have, let alone who controls and revises this protocol.

Again, if you want these things changed, we, I,  have to know exactly what the problem is and what the fix should be.  We (Q&T) and you (D&A) obviously are not communicating well enough.  I inherited the policy, I did not create it.  I imagine it arose after repeated bad experiences stemming from the implementation of new features in maintenance releases.  It was probably just a reactionary attempt to fix the problem and may or may not be the best solution.  I don't know the answer to that. 

We've been advocating for this to the core for 3 years now. How many more vacous promises will the core recind on, like they recinded on pT, WCAG 1.0 compliance in J 1.5 and other stuff ?

That is not a question that I can answer.  It is a question for the developers.

You and others may or may not agree with what I have said, that is fine.  My point is simply this, I will not be held liable for decisions made by others before me.  They were not my decisions and for you (or anyone) to hold me responsible for those decisions is wrong.  If you feel there is a problem and that I might be able to help fix it, talk to me about it.  If you do, don't bring your bagage with you though.  I am more than willing to critically evaluate the processes and systems that the project has in place with the hope of making them better.  I am not willing to sit around and listen to people rag and bash the project all day about its problems and do nothing else about it.  If you want to yell and get mad at someone, buy software, if you want to be part of a great project, stay here and help out.

[absalom]

I know it's not your baggage. I'm still, however, waiting for the answers (even if they don't come from you, as you're now the 'new guy' leading the stable releases). I am willing to help out.. it's just more often than not the U&A guys have been sidelined time and again by the rest of the organisational meritocracy. It happened with Mambo when the core changed functionality without informing the 3PD Standards, it happened (as far as I can tell) with Vavroom's ideas for J! being shelved because they were too advanced and/or too controversial for the rest of the core and it's happening over and over again every time there is a maintenance release. The same problems arise, the same hacks have to be recoded and reapplied, and nothing ever changes. Yet, like I said, the technology is already here and has been for a while. It's also been tried and tested as "hacks".

You can already find my thoughts on what should be done to solve the problem of version control and accessibility within the Working Groups and Development Wiki.. I know it's private discussion compared to this, but I do need to keep the wider community informed that I feel the core is again dropping the ball when it comes to U&A stuff.

I've already submitted to the tracker on code that was not accessible or standards compliant with the most elegant solution that I and others (usually in commercial releases I've done, where the end client gets screwed round by J! not doing what they expect) and been told it's not a bug and therefore not worth the effort. I've also been told that it wasn't worth the effort including simple, subtle fixes of this nature in the 1.0.x codebase, even if those fixes meant certain things needed to be rethought or redesigned. See, I've done exactly what you would describe as a beneficial course of action, and got nowhere..

So where do we go from here ? Is there any change in the mentality of the core vs everyone else ? Can whatever protocols and procedures we have in place be tested and perhaps rethought ?

[RobS]

When were you told that?  I don't think I did it.  If so, call it out to me and I will look at it again.  If it is not something that I did you are kind of illustrating my concern.  You may in fact have been told that before when other people ran the tracker but they don't run the tracker any more.  Give me a clean slate and lets work together to make Joomla! better

Again, I am open to analyzing these systems, I am trying to be more open about communication and goals, I am one of the advocates for a more open project in general.  I am trying but I cannot do it alone, I need others to try too. 

[absalom]

When were you told that?  I don't think I did it.  If so, call it out to me and I will look at it again.  If it is not something that I did you are kind of illustrating my concern.  You may in fact have been told that before when other people ran the tracker but they don't run the tracker any more.  Give me a clean slate and lets work together to make Joomla! better

Again, I am open to analyzing these systems, I am trying to be more open about communication and goals, I am one of the advocates for a more open project in general.  I am trying but I cannot do it alone, I need others to try too. 

Fine with me. There should be an [Under Review] forum post of mine regarding backports of 1.5.x accessibility fixes I've suggested into 1.0.x somewhere in the [Solved] area of the 1.5 dev forum. Unfortunately, because I don't have mod rights, I couldn't rescue it out of the Solved pile since other people deemed it Solved when it wasn't. How's that for a start?

Edit: link now found.. http://forum.joomla.org/index.php/topic ... 79514.html

The reason I'm using these backports as an example is that there are reports a8e doesn't play nice with sIFR in its basic version and the only reason that is the case is that the fixes I put in the tracker for 1.0 were never carried through, leaving both a8e broken and the ongoing version management not solved. If the fixes went into the trunk in the first instance, a8e would never have been reported with this issue. I do believe RunDigital's accessibility hack also suffers from the same version control / accessibility / sIFR combo bug.

[RobS]

It would be easier if you found it for me and just gave me the link.  I don't mean to sound lazy or self-righteous or anything like that but I have a lot of stuff going on right now and if I put it off I might forget about it and then we won't get anywhere.

[brian]

how is this for a suggestion.
when joomla 1.0.12 is released a new team of people take that and start the work to produce an accessible  version of joomla.

they can take concepts from existing solutions and have the benefit of knowing they are working on a stable release. in addition it is likely that the only o
post 1.0.12 releases will be security one's and they should be easy to role into ann accessible release. the problem in the past with the accessible hacks was that they altered core making updates hard. this won't be a problem now as there will be nothing new in the 1.0x tree.

[absalom]

how is this for a suggestion.
when joomla 1.0.12 is released a new team of people take that and start the work to produce an accessible  version of joomla.

they can take concepts from existing solutions and have the benefit of knowing they are working on a stable release. in addition it is likely that the only o
post 1.0.12 releases will be security one's and they should be easy to role into ann accessible release. the problem in the past with the accessible hacks was that they altered core making updates hard. this won't be a problem now as there will be nothing new in the 1.0x tree.

That was the initial suggestion to Vav for the 1.5 build when it was envisioned at 1.1. U&A would produce an alternate version, however, the problem of version control still causes significant issues, even at the best of times (as accessibility is seen as an addon, not as a core philosophy or ideology). As the rest of the U&A seem to be in limbo or lurking, plus having next to no direction as to the status of all design philosophies post-Vav's departure from Joomla, it again looks to be against insurmountable odds that such a thing would be attempted.

And anyway, why post .12 ? why not post .11 ?

[brian]

well post 1012 I think there will be new opportunities for people like yourself to do this. the problems in the past was that joomla was a movable target and many suggestions would quickly become obsolete and this lead to much frustration. as 1.0.12 will NOT be a movable target things should be much  easier for a team to produce an accessible  version

[absalom]

well post 1012 I think there will be new opportunities for people like yourself to do this. the problems in the past was that joomla was a movable target and many suggestions would quickly become obsolete and this lead to much frustration. as 1.0.12 will NOT be a movable target things should be much  easier for a team to produce an accessible  version

'Should' being said with baited breath and some cynicism considering what I've seen with U&A direction over the last year or so (both in Mambo and Joomla). At least I'll be able to catch up with another of the J! U&A guys for a face to face next week, so we may become a whole lot more vocal on this topic than simply me guarding the fort for the last 6 months on this. In that time the admins have closed down the design dev wiki, sectioned off the D&A pages and I haven't heard a meaningful 'peep' from my supposed working group leader in the core as to what the heck we're meant to be doing in the interim until our 'time' midway through 1.6 when pT goes hardcore throughout the code and we get the freedom to play. Perhaps we're meant to be knitting blankets or something??  :P

And then we again have the movable target of 1.5 itself and having the same version control issues all over again..

[Jinx]

Absalom,

While reading this posts I wonder what you are trying to prove here. U start by personal attacking one of our core members about an issue that isn't Joomla! project related and then u drive the discussion into the Joomla! accessibility area where u attack the direction of the project, an area where u are in charge off.

...next to no direction as to the status of all design philosophies post-Vav's departure from Joomla...

Have u ever asked ? If u did we would have directed u to the roadmap and D&A working goals set out in the working group by Nic in october last year. If i remember correctly u were already part of the D&A group at that time.

It's not the task of the coordinator to 'boss' his members. He is there to coordinate the working group and act as a communications channel between the members and the core team. Working groups have a large freedom in defining their goals and actioning them.

For the D&A working group the goal was and still is to bring Joomla! community accessibility specialists and designers together to :

1. Create an official specification to guide third party developers in creating accessible extensions.
2. Create an official template package that overrides all the html outputted by the system to demonstrate the specification

This goal and a roadmap was layed out in the D&A team is almost a year old and was set after the London Summit. Since then we have tried to get you (all the D&A working group members) to make something happen. Myself and the different coordinators for the D&A working group tried hard, very hard,... we created a roadmap, opened a wiki, had discussions... and what did we get ? Nothing, zero, zip, ...much to our own frustration.

Most of the working group members have created their own accessibility solutions for Joomla!. I can't undo myself of the perception that the members of the working group aren't capable of creating a consensus about how accessibility needs to be implemented in Joomla! and as a result do it on their own.

At least I'll be able to catch up with another of the J! U&A guys for a face to face next week, so we may become a whole lot more vocal on this topic than simply me guarding the fort for the last 6 months on this.

I hope vocal means, we will make some good things happen. I still want to believe this is possible...

Johan

[absalom]

While reading this posts I wonder what you are trying to prove here.

The value of accessibility, both as a credible practice instead of some marketing buzzword, to the wider Joomla community and to the core.

U start by personal attacking one of our core members about an issue that isn't Joomla! project related and then u drive the discussion into the Joomla! accessibility area where u attack the direction of the project, an area where u are in charge off.

I didn't drive it that way. Shayne commented that people should be applauded for accessibility work, but that just opens the can of worms as to why the trunks don't include that work (by and large).

I am actually somewhat shocked by your statements above. I never knew I was in charge of this ?  (Especially in light of the track record regarding the core and U&A work over the last year, not to mention the other U&A guys and their "roles")

Have u ever asked ? If u did we would have directed u to the roadmap and D&A working goals set out in the working group by Nic in october last year. If i remember correctly u were already part of the D&A group at that time.

Yes, I've asked. I've asked regarding semantics, how to truly seperate content and presentational aspects, how to make that stuff "modular" and what that means in terms of solving the inherent problems across the Mambo/Joomla world. The problem is that every time I ask for stuff to be considered as part of projects now, they get shelved for a later release, a release that, by and large, never eventuates. The dates and times and project spec on which we're meant to be working to deliver these solutions (or at least direct the core to implement pre-existing solutions) shift like a sandstorm.

It's not the task of the coordinator to 'boss' his members. He is there to coordinate the working group and act as a communications channel between the members and the core team. Working groups have a large freedom in defining their goals and actioning them.

So if the U&A working group recommends deploying a pre-existing accessibility solution into the trunk, what happens then ?

1. Create an official specification to guide third party developers in creating accessible extensions.
2. Create an official template package that overrides all the html outputted by the system to demonstrate the specification

1 was completed initially by Nic and has remained available since he departed.
2 has no firm guidelines for release, since the version dependency and version control issues remain present. By and large, the U&A group has consensus as to what an accessible solution should look like. The technology is already available and demonstrated as stable at least for the 1.0.x branch. Like I said above, there is no technological reason why it isn't achievable.

This goal and a roadmap was layed out in the D&A team is almost a year old and was set after the London Summit. Since then we have tried to get you (all the D&A working group members) to make something happen. Myself and the different coordinators for the D&A working group tried hard, very hard,... we created a roadmap, opened a wiki, had discussions... and what did we get ? Nothing, zero, zip, ...much to our own frustration.

You may have thought we got nothing, but we do have some consensus as to what should and shouldn't be done in regards to accessibility.

Most of the working group members have created their own accessibility solutions for Joomla!. I can't undo myself of the perception that the members of the working group aren't capable of creating a consensus about how accessibility needs to be implemented in Joomla! and as a result do it on their own.

We know how it can be deployed, it's just the code "flavour" that differs in understanding (h1 vs h3, and minor nuances like that). I am of the same mind as Nic in regards to the overall long term plan for Joomla, though - that accessibility has to become part of the core philosophy of Joomla, and I think my fellow U&A WG members would agree with me in that the only way to solve the version control/update issues is to make accessibility a core function that anyone can use (even external CMTs)

If you actually went through all the current accessibility solutions available (and I've done this), you would actually recognise how much they stay the same.

I hope vocal means, we will make some good things happen. I still want to believe this is possible...

That's the question. Would a group consensus that we adopt a pre-existing solution be considered "good" by the core ?

[absalom]

The codebase for Joomla has evolved over time and whilst the U&A WG have been reaching consensus as to what the direction should be. U&A has ascertained 3 possible paths to take. As this is a public poll, you can only vote once and you can't change your vote

[Jenny]

A)It actually would be more telling if you posed a poll that asked people if they know what accessibility is and if they know how to implement it in their design skills.

B)If the U&A WG can't come to a concensus what good does this poll do?

You guys need to figure out together what you think the best path to take is of the three and get on with it already.  If you all can't do that then the poll is useless. 

Edit: And why are you including forking? 

[absalom]

A)It actually would be more telling if you posed a poll that asked people if they know what accessibility is and if they know how to implement it in their design skills.

Not really. I already know the statistical breakdown.. 80 to 90% of sites and designers don't follow it because they don't know how, why or what to do. This is seen worldwide across all web markets, and Joomla is pretty much international in this respect, so by implementing it as a core perspective, instead of some perfunctory addon / hack / fork, the mentality shifts from being "eye candy" to needed.. If the reports remain correct, 1 in 4 visitors to any website have some kind of accessibility issue (include the basic pixel height vs relative height text resizing). So we know the problem exists, we know how little take up there actually is, and we have been working on ways to resolve this so we don't have to keep on churning out accessibility hack after accessibilty hack every time we have a maintainence or significant version update. By placing accessibility as an intrinsic part of core "business", the people who use Joomla will likewise gain the benefits and training and experience of those who've been dealing with these issues for the last few years. People will get trained, people will learn, and people will understand..

B)If the U&A WG can't come to a concensus what good does this poll do?

I'm betting that we can and already have. The accessibility solutions currently out there don't vary from each other too much, so it's more personal preference and "eye-candy" accessibility ideas that we differ on. That suggests to me we just need to build in some extensibilty so people can flavour the accessibilty structures to their liking.

Edit: And why are you including forking? 

Why are we including forking ? Because that was the direction given to us originally by the core team. They offered up that we create a "template" fork to satisfy WCAG guidelines (as stated by Jinx). I'm still of the mind that it's not the best, most elegant solution to the problem, when the problem exists in the way the code code interacts with each CMTP.

[vavroom]

Again, you have to get the chassis built before you can install the really cool leather seats. 

Accessibility is not about the really cool leather seats, it's about being able to drive the bloody car...

[absalom]

Again, you have to get the chassis built before you can install the really cool leather seats. 

Accessibility is not about the really cool leather seats, it's about being able to drive the bloody car...

Seconded, thirded and whatevered.. I'm currently porting some of my early accessibility solutions from 4.5.x days into Accessible Joomla, and it's annoyingly simple (and likewise perversely irritating) how little has changed in 3 years. It shouldn't be this easy to crossport solutions from ancient code into the absolute bleeding edge, should it? :P

And like I said, we can drive the car. We can even make it a Ferrari.. We don't have to have the latest v12 Ferrari immediately, though.. I'm quite happy with a drivable Ferrari..

[vavroom]

Some further thoughts...

On the U&A folks not agreeing.  I think Absalom hit it right on the head.  We *do* agree.  We agree we need "a shirt", what we don't agree on is minor, which colour shirt. 

I've heard a lot of people say that J! is dedicated to accessibility, but again, as Lawrence points out, any discussion about making accessibility happen now is kind of shrugged off.  There are always good reasons, but it gets shrugged off anyway.  Accessibility should be an integral part of the core, NOT an add-on, something that gets worked on afterwards.

The suggestion that 1.1 would be released "as is" and an accessible package would follow made some sense at the time, there was a lot of work that happened in 1.1, and in order to make it happen, there wasn't time to include accessibility changes.  But this was over a year ago.........  In that time, there would have been plenty of time to actually review 1.5, or whichever version will finally come out, and include accessibility work out of the box.

So in fact, I perceive mixed messages:  on the one hand, we're told "yes accessibility is important", but on the other hand, we're shown that it'll always be the poor cousin.  It wouldn't be so bad if the message matched the actions.  You tell me that accessibility is not a top priority, I'll accept the add-on package.  But you tell me it is perceived as important, then you better act the part (using a general "you" here, not pointing the finger).

Rob is right, fairly significant changes as accessibility would require doesn't really fit in a stability release such as .12.  Thing is, when has the J! project stopped and really not introduced fairly major changes at stability releases?  It happened in the pre-split days, and kept happening afterwards.  So while I don't have a philosophical issue with not making major changes on .12, I'd ask not to use that particular argument in view of historical release behaviours.

What gals me is that for whatever reasons, accessibility is not happening, but that those who have done the work to make it happen get blamed for no result.  I was rather visciously attacked at a German accessibility meeting last year, and following that on the J! internal mailing list, being accused of stopping accessibility.  This was not the first nor the last time that I was blamed for seeing no movement in making accessibility happen.  Now Jinx is saying it's Lawrence's fault for having no result there.  Guys, this ain't right.

You commit to accessibility happening, and you make it happen, or you state out plainly that accessibility ain't particularly important to you, and it'll happen whenever it happens. 

[eyezberg]

What needs to be done in 1.5 to make it accessible? Is it much that needs to be changed?
I mean really, as long as these discussions keep going on (for years!) and nothing happens, just throwing the ball back'n'forth: you do it/no it's your job, what good is all this? Loosing credibility, loosing clients wo have to use accessible websites because of the law!, and wasting more time..
The past is gone.
Right now, there are a few solutions to existing shortcomings around, such asa more accessible menu, SEF Patch, a8e, Run Digital etc..
These are widely used and tested, they work! They might not all do the same thing, or fix the same issues, but they all add to accessibility.
But: they all have to be recoded to patch core after every update (12 versions in 12 months). This is a waste of time and energy and ressources, more obvious it couldn't be. If really you refuse to add any of this to a .x release in the 1.0 codebase (suggested before: release .12 to fix all the current issues, nothing else. Then release .14 -superstitions- as "Accessified Joomla!" -note I didn't say accessible..!), then at least add the proven bits and pieces to 1.5?
Can this discussion yield something usefull instead of the same things repeated I've read time and time again over the last years please?
U&A, get those code bits together into one suggestion to show consensus and provide something more visible than forum posts, Core look at them, and then tell us if they can be included and when, or why they can't..?!

At least if Nic can make a comeback here to show how important the matter (still) is, then please all show some respect and try to get something out of this?

... I probably should've kept outta here...

PS: about the poll: "Wait till 1.6.x gets full patTemplate, then fork": I thought pT is not the desired solution due to performance issues?

[absalom]

What needs to be done in 1.5 to make it accessible? Is it much that needs to be changed?

Really.. yes. Lots. The first step is to get accessiblilty as part of the core philosophy and ideology, not merely as an addon. Without that, we're generating hacks every time there is a release, maintainence or otherwise. That seems a significant wastage of resources. Why continue to generate hacks/addons when there is a better, more elegant way (and people have been saying there is a more elegant way for.. what.. a year or so now) ? That said, I consider it an acceptable solution to accesify a "final" release of the 1.0.x stream as it's being grandfathered.

Right now, there are a few solutions to existing shortcomings around, such asa more accessible menu, SEF Patch, a8e, Run Digital etc..
These are widely used and tested, they work! They might not all do the same thing, or fix the same issues, but they all add to accessibility.
But: they all have to be recoded to patch core after every update (12 versions in 12 months). This is a waste of time and energy and ressources, more obvious it couldn't be. If really you refuse to add any of this to a .x release in the 1.0 codebase (suggested before: release .12 to fix all the current issues, nothing else. Then release .14 -superstitions- as "Accessified Joomla!" -note I didn't say accessible..!), then at least add the proven bits and pieces to 1.5?

The problem, as always, is version control. Time and again we've had accessible stuff KOed by updates to the core. Which is why I'm wondering what I've recommended for 1.5 and beyond (which is similar in scope to what Nic directed as part of his time inside the core, from what I can make out) will ever be adopted. I know Andrew Eddie did some work along my line of thought, and I haven't heard from the core as to how fruitful it was in spreading further across the core codebase.

Can this discussion yield something usefull instead of the same things repeated I've read time and time again over the last years please?
U&A, get those code bits together into one suggestion to show consensus and provide something more visible than forum posts, Core look at them, and then tell us if they can be included and when, or why they can't..?!

That's what I'm hoping for.

At least if Nic can make a comeback here to show how important the matter (still) is, then please all show some respect and try to get something out of this?

I'm trying to..

PS: about the poll: "Wait till 1.6.x gets full patTemplate, then fork": I thought pT is not the desired solution due to performance issues?

We need some "templating" language to simplify the markup and so resolve depedence issues - pT seemed nice since it was originally working back in the 4.5.3 Beta (the real one, not the MF one). It also was scoped that we could potentially "hot-plug" the same accessibility benefits we had envisioned for the core into external CMTPs and such logic does require template architecture.

So the game plan is thus:

1) Accesify the grandfathering release of the 1.0.x stream (will most likely include a SEF upgrade as well)
2) Get accessibility as a core philosophy as part of 1.5 and beyond. True SEF functionality will also need to come on board as part of this, but the SEF changes remain minimal in scope (in discussions I've had with Ken and others in the SEF space) compared to what we need to get accessibility as true "core" functionality and ideology in order to deal with the version control issues.
3) Release 1.5.0 with out of box accessibility.
4) Go down to the pub and celebrate that all versions from 1.5.0 onwards will be kept in line with accessibility (plus they can be upgraded as the standards develop and change over time due to the hot-plug / extensible nature of what we're suggesting)..

1 is achievable now, both ideologically and technologically.
2 isn't, as the core disagrees (as far as I can tell) with the direction U&A need to do their job..
As 2 isn't achievable, 3 is vapourware, and nobody ends up down at the pub celebrating.

[absalom]

I hope vocal means, we will make some good things happen. I still want to believe this is possible...

I've been talking with Leonard from Aurum3 regarding what we do for 1.5 and we have agreement, both face to face and in other discussions, that 1.5 should include accessibility and usability as a core function. Angie Radtke has also agreed with me (as far as I can tell, due to difference in language communication) that this go ahead. I haven't heard from Luke, but since we're looking to have his work at RunDigital affect the 1.0.x accessibility stream (from what Angie has told me), I'm assuming tacit agreement on that part. Greatpixels hasn't responded.

So we have 3 U&A people in consensus (maybe even 4), 1 ex-core leader in consensus, and one &UA no-show and a few of the people I'm networking with at Web Directions South also affirming that accessibility should be considered core from the ground up - essentially if J! included accessibility as the base for everything  being done, more people will use it

It now remains up to the core as to how things pan out in light of this.

Random comment for the day: "I aim to misbehave"  :P