Accessibility solutions within Joomla!

[eyezberg]

Lawrence, do you happen to have the links to the overview pages ( i think they existed on the forums) of the various team members of the different teams? I ask because it's not very telling if you just say "3 in consensus" without people knowing out of how many..
Also, you say there's lots to do in 1.5 to make this happen, anyting more precise than that? Could the people you mention contribute code to get this into Core faster?
Would be great if it's not too late now..

[Jinx]

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

That's great Lawrence. Good to hear the experts all agree. I don't think there is anyone in the community who feels any different, 'including the core team'.

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

Actually that's where u go wrong and to me this is exactly the root of the problem. For one year now we have been asking the D&A WG to work out how accessibility needs to integrated into the Joomla! codebase and again U look at the core team for a solution. What do you want to hear ? That accessibility matters. Offcourse it does, just like documentation, internationalisation,  security, .... matter. 

Joomla! is driven by the many contributors in the different working groups, not by the core team. The core team is made up out of the working group coordinators. Their main task is to facilitate crossworking group coordination. Each working drives a specific area of the Joomla! project and has it's own goals and tasks. For the D&A working group this is :

To strive towards creating the most accessible and flexible content management system on the planet. This working group will ensure that future versions of Joomla! have the ability to render according to various accessibility certifications including WCAG and 508 compliance, as well as being flexible enough to support others.

The D&A group will also provide design and layout assistance for any Joomla! effort that requires it. This includes but is not limited to: Joomla! templates both front and back-end; Joomla! web sites and supporting sites; Joomla! brochures and advertising material; Logo and marketing work.

Our overall goal is to provide Joomla! with a professional public presentation and provide the most accessible content management system possible.

Quote from : http://dev.joomla.org/content/view/19/53/

I think this statement is pretty clear. So I'll return the question :

- What do the people u talked to mean with 'including accessibility and usability as a core function' ?
- Can these people clearly outline where they think Joomla! 1.5 is lacking
- Can these people clearly outline what changes they think are needed

We all agree accessibility and usability needs to be improved, it's upon the D&A working group to drive this process. I'm looking forward to the results of your discussions and I'm happy to welcome anyone who want's to help as a member of the D&A working group.

Johan

[Jenny]

Lawrence, do you happen to have the links to the overview pages ( i think they existed on the forums) of the various team members of the different teams? I ask because it's not very telling if you just say "3 in consensus" without people knowing out of how many..
Also, you say there's lots to do in 1.5 to make this happen, anyting more precise than that? Could the people you mention contribute code to get this into Core faster?
Would be great if it's not too late now..

Is this what you are looking for eyez?  http://dev.joomla.org/content/view/19/53/

[eyezberg]

Cool, MMMedia, never noticed that Working groups link appreciated!
I have pointed lukewill to this thread, just in case.

PS: if anything gets done, can this be considered? or something along those lines, I admit I haven't checked if there is something already in 1.5

[absalom]

Lawrence, do you happen to have the links to the overview pages ( i think they existed on the forums) of the various team members of the different teams? I ask because it's not very telling if you just say "3 in consensus" without people knowing out of how many..
Also, you say there's lots to do in 1.5 to make this happen, anyting more precise than that? Could the people you mention contribute code to get this into Core faster?
Would be great if it's not too late now..

Like I said, for 1.0.x, this is achievable now. I'm working with the rest of the U&A team at the moment in co-ordinating which bits go where for it (what determines the best ease of use for the final 1.0.x kinda stuff - RunDigital, a8e, kandalf, Aurum, my own). Each of us has contributed something unique to U&A in how we've done our builds over the last few years, so all I'm really doing is taking a group consensus and aggregate of our abilities and merging them into one final "hack" that will be applied to the core.

Johan made a fly by night comment that the U&A guys weren't in agreement, and by doing what I've done, I've shown that the core has the wrong idea about how U&A has gone about getting the solution right.

1.5 needs to include what Andrew Eddie started to show me as the functional spec for 1.5 has the template for each "bit" that makes up a component, module or plugin as part of a greater template library. All these discussions have happened previously. The significant limitations on this are:
1) We don't know if Andrew's work in regards to what we've discussed actually went anywhere - how much code did it end up affecting or was it merely proof of concept ?
2) We probably need some other team to build the template library structure (cue the bunfight that's been happening over pT). We know what should go in the template library once the structures been determined and how it should go in there, but from a logistically capacity, it's currently beyond my abilities. I'll deliver a significantly more detailed functional spec sometime next week to solidify what we need and how we envision to do it, but we need the support from other teams in this respect.

[absalom]

PS: if anything gets done, can this be considered? or something along those lines, I admit I haven't checked if there is something already in 1.5

I'm already considering it as part of the SEF upgrade for 1.0.x..

[absalom]

Actually that's where u go wrong and to me this is exactly the root of the problem. For one year now we have been asking the D&A WG to work out how accessibility needs to integrated into the Joomla! codebase and again U look at the core team for a solution. What do you want to hear ? That accessibility matters. Offcourse it does, just like documentation, internationalisation,  security, .... matter. 

We've told you how.. It's like Lego, remember ?? You deal with each "bit" that makes up a CTMP individually, put those "bits" into a global library (we recommend something like pT to simplify the final codebase for developers) and then you allow cascadence and inheritance to flow the accessibility benefits from how you style each "bit" in the library. This is nothing new.. Nic was talking about it inside the core the same time I was talking about it elsewhere.

Because it becomes a template library, it then allows:
a) significant code reuse by 3PDs, who will likewise gain the accessibiliity benefits provided they follow the design guidelines for building CMTPs in this new way.
b) customised flavours of accessibiliity aka extensibility. Say you have a client who requires ATAG compliance. All you then do is customise the library to suit ATAG guidelines and apply it to the core. Cascadence and inheritance take care of everything else. It also means the U&A team can each have their own customised accessibility template they want they want to do it (h1 vs h3 discussions)
c) it means we can potentially make the backend and frontend accessible in one deployment. As the backend of Joomla runs CTMPs as well and as we're going to be changing how the CTMP design architecture actually works to allow cascadence and inheritance, it would seem logical that the same CTMP "bits" affect both frontend and backend when they're able to be documented and independently customised in a library.

To strive towards creating the most accessible and flexible content management system on the planet. This working group will ensure that future versions of Joomla! have the ability to render according to various accessibility certifications including WCAG and 508 compliance, as well as being flexible enough to support others.

And the solution we're offering does exactly that. You want WCAG 2.0 instead of 508 ? You just change the template. The standards change a year or so later ? You just change the template. Cascadence and inheritance take care of everything else.

- What do the people u talked to mean with 'including accessibility and usability as a core function' ?

The same thing. That we do no more hacks and that whatever we do as part of U&A benefits everyone. To quote Tim Berners-Lee:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

To provide access by everyone, you need to change the structures so whatever U&A does to implement accessibility in 1.5 affects everyone (including the CTMP devs).

- Can these people clearly outline where they think Joomla! 1.5 is lacking

Haven't we already done so for the last year??? No more hacks.. No more retrofits. We know how to solve the problem.

- Can these people clearly outline what changes they think are needed

Well, when we have Leonard, myself, Nic and Angie saying we should be using some form of accessibility templating so it affects everyone in the CMTP layer, instead of resorting to retrofitting hacks to certain components, modules and so on, I think the take home message is obvious..

[MarkV]

Gimme a option 5 . Build it in the 1.5 core.

[RobS]

Lawrence, do you happen to have the links to the overview pages ( i think they existed on the forums) of the various team members of the different teams? I ask because it's not very telling if you just say "3 in consensus" without people knowing out of how many..
Also, you say there's lots to do in 1.5 to make this happen, anyting more precise than that? Could the people you mention contribute code to get this into Core faster?
Would be great if it's not too late now..

1.5 needs to include what Andrew Eddie started to show me as the functional spec for 1.5 has the template for each "bit" that makes up a component, module or plugin as part of a greater template library. All these discussions have happened previously. The significant limitations on this are:
1) We don't know if Andrew's work in regards to what we've discussed actually went anywhere - how much code did it end up affecting or was it merely proof of concept ?
2) We probably need some other team to build the template library structure (cue the bunfight that's been happening over pT). We know what should go in the template library once the structures been determined and how it should go in there, but from a logistically capacity, it's currently beyond my abilities. I'll deliver a significantly more detailed functional spec sometime next week to solidify what we need and how we envision to do it, but we need the support from other teams in this respect.

Lawrence, I am getting the impression, repeatedly, that you haven't actually taken a look at 1.5 lately.  Is this the case?

I am assuming it is the case because of your comments about not knowing what has been adopted and what has not.  I also think that in general, we are talking about different things.  Johan and myself are trying to focus the conversation on 1.5 while you keep continuing back to 1.0.  I have to say that it is my opinion that 1.0 is what it is as far as accessibility and it is not the place that your, and the rest of D&A's or U&A's (that is another thing, why do you keep calling it U&A still, it is D&A technically), energy is best spent. 

In regard to what Andrew Eddie suggested, I think that it has been implemented (in the front end, not the backend, yet), if I understand what you are saying.  I tried to point out in one of my earlier posts that all of the functional logic for a front end component in the 1.5 core has been separated from the actual rendering logic.  Hopefully, I can illustrate this point a little bit better.  In 1.5, components are broken up into several pieces, the two most relevant to this conversation are Models and Views.  A model is class that contains/controls the functionality for how the component does what it does, functionally.  For example, if my component needs to save something in a cookie, it would to that inside the Model.  On the other side of that is a View.  A View is best understood in two parts (this is just my opinion), the first part of the view does a little bit of logic in interaction with the Model, so, if my component fetches information from the database, it will store it in an object/array/var/whatever inside the Model, then, the View has to get that information out of the Model so it fetches the Model and then takes whatever item out of it that you want, and puts it in the Views scope.  Once all of that is done, we get to the really nice part about 1.5 and something that I think you will like.  The view will include a separate file that contains nothing but the display logic.  Depending on the format requested (HTML, RAW, PDF, etc.) there will be a separate file, and the really awesome part about this whole thing is that a template, like your standard template packages, can override this and call a display logic file of its own!  Isn't that great?  I think it is awesome!  All of the HTML (for example) is kept in this one file for that one format and the file to open, instead of the default, can be overridden by a template.  It is a great system that I am really just learning the power of but I have to say, it opens up a lot of options that were not available in 1.0.  I am barely scratching the surface of what the new framework can do, it can do many cooler things than just this, for example, you can extend the JView class's render function to include a render function all your own that will do something totally different than what the original one did.  There is a huge amount of power there now that never existed before, with that power, you can do just about anything you want for accessibility without having to worry about versioning issues because you won't have to hack core files anymore, you can just extend them or override them.

To better understand, as it may be still unclear.  I have attached a few notes to further illustrate the point.
- A Model should only contain the business logic, it does not output anything to the screen
- A View is really the guarding of the whole system, the View calls the Model that it wants and the View pulls in the data that it wants from the Model.  There is a file that should do this separate from the file that actually contains the output, it is normalling named after its format type, something like view.html.php or view.raw.php for raw output.
- That View controller (probably the wrong technical term) like view.html.php will call a separate file in the "tmpl" directory that will actually contain the HTML code to be displayed.  This default file is actually called, default.php.  Inside default.php is nothing but the display out.  This file is normally almost all HTML (in the case that html is the output type) with maybe a small amount of PHP if the output needs to loop through something.  This file doesn't have to be called, if your template includes a replacement for it, that file will be called instead making this one output nothing!  So, if the core one outputs tables by default and you don't want tables, you can create an override that outputs only s and s or whatever you want.

I really hope that this made sense and that you see the amazing power that is now possible with this system.  I have only been really working with it for a couple of days while writing a couple of components/modules but it is really awesome.  You can do so much more than you could do before and it isn't limited to just CMP developers, that power is available in templates as well.  I went into all of that detail because I really hope to get some of you guys from D&A inspired, 1.5 will be able to do so much and that includes the ability to provide a 100% accessible website if you want it to.  No, the core components won't be 100% accessible out of the box but a good template can fix that now, and you don't need the core hacks and the version control headaches anymore.  For the first time, I think it will really be easy to do and that is something that I am really excited about.  You can set your old woes to rest, it will be better from now on. 

[eyezberg]

RobS, that sounds like something that can be developed in parallel to Core: just provide a set of "accessible" templates for all of core, and you're done -mostly.
But afaik (but I don't know much I admit), there's more to it than just the code/content separation, there's also other things like menu item accessibility with titles or alt or tooltips or whatever, custom(izable) page titles for all "pages" etc.. no?
It would be nice if the workgroup members could post an exhaustive as possible list of needed / desired changes and additions / improvements?! 

[Jenny]

The problem I see with an "exhaustive" list is then you get into code bloat.  It doesn't have to be exhaustive.

I think the approach should be what are the basic elements that have to implemented/altered to the core code, that would then allow the most flexibility to allow users to implement specific accessibility functions that they specifically need in their sites using extensions.

I don't think it all has to go into the core.  The core should be the frame work in which people can then mold their sites for their uses and specific needs.  The basic core should meet the minimum basic standards and guidelines, in what it contains out of the box.  After that it should be up to individuals to implement higher levels if so needed/desired. 

Just my thoughts on it. 

[RobS]

RobS, that sounds like something that can be developed in parallel to Core: just provide a set of "accessible" templates for all of core, and you're done -mostly.
But afaik (but I don't know much I admit), there's more to it than just the code/content separation, there's also other things like menu item accessibility with titles or alt or tooltips or whatever, custom(izable) page titles for all "pages" etc.. no?
It would be nice if the workgroup members could post an exhaustive as possible list of needed / desired changes and additions / improvements?! 

Joe,

I am sure there is a lot more to accessibility than what I discussed.  I will happily admit that I am nowhere near an expert on the subject either.  I was trying to point out that we are making it easier to implement and even easy to implement by a 3rd party without the typical issues of 1.0.  The ease comes from the flexibility.  But, I don't know how the menus fair as far as accessibility, that would require somebody with more knowledge on the subject.

[eyezberg]

Yes, that is what would be good: more people commenting here on what changes are needed (ok, maybe not exhaustive) to fullfill: most requierements (step 1); all requierements (step 2), anything else etc.. like de and his extended menu and just anything more usefull than "there's lots of things to do". A list of things to do, so someone can estimate if and in what proportion it's feasable.

[absalom]

Yes, that is what would be good: more people commenting here on what changes are needed (ok, maybe not exhaustive) to fullfill: most requierements (step 1); all requierements (step 2), anything else etc.. like de and his extended menu and just anything more usefull than "there's lots of things to do". A list of things to do, so someone can estimate if and in what proportion it's feasable.

That's just it. Most or all or anything in between become redundant when you're talking about a library that has cascadence and inheritance across an entire CMS design and deployment structure. It either is providing the right output or it isn't.

Like I said, all you do is change the template. Need WCAG AA ? (Though I see no rationale for such a request when the template in question can be forseeably designed from the outset to AAA compliance) Dumb it down..

Each component, module, plugin and template is made of semantic areas, such as headings, intro texts (aka summaries), articles and processes on how it affects output (the latter is primarily plugins-based). Why can't we shift these semantic areas into a core library, and then let tried and true principles of design behaviour like cascadence and inheritance to take care of everything else?

Postscript: contrary to MMMedia's notions, it's not an exhaustive list. We are not documenting how every HTML/XHTML element is to be styled and placing that in a library. We are taking the key sematic "bits" that make up all forms of output (backend & frontend) and placing that in a core library, and then using something like pT so devs (both internal to the core and elsewhere) can do less coding for each component and get better, more accessible output for their work.

U&A in this respect just generate the templates that are needed, and everyone is happy cos the problem is finally solved, once and for all.

[absalom]

I am assuming it is the case because of your comments about not knowing what has been adopted and what has not.  I also think that in general, we are talking about different things.  Johan and myself are trying to focus the conversation on 1.5 while you keep continuing back to 1.0. 

So Johan forcussed the conversation onto 1.5 by trying to blame the D&A team for lack of consensus, by claiming we didn't agree on what needs to be done and what the best path for it to be done for 1.5  

We already agree. We mostly always have. Sure, each D&A team member sees it turning out slightly differently due to their own perspective, but we all agree on the following major points which haven't been adopted by the wider J! development:

• No more hacks, whatsoever. We know how to solve this, we know what must be done.
• Use templating to simplify it down, both for the core and for 3PDs
• Use inheritance and cascandence. Why use them ? To resolve the issues of CMP dependence for styling

We know retrofitting is, by and large, an inadequate response to poor design principles. Since we've been retrofitting (aka "hacks" / "patches") for accessibility for a while now, that leaves the design structures themselves at fault. We've  (D&A/U&A) been repeatedly advocating and evangelising that the direction for accessibility is that it has to be important instead of this seeming tacit political gamesmanship that seems to be prevalent here where the core says accessibility is important but does nothing to implement the design and structure changes needed for D&A to solve the inherent problems in the system.

I have to say that it is my opinion that 1.0 is what it is as far as accessibility and it is not the place that your, and the rest of D&A's or U&A's (that is another thing, why do you keep calling it U&A still, it is D&A technically), energy is best spent. 

We've told the wider core team what needs to be done for 1.5 for a while now. Why is nobody listening (and at worst, blaming us for a lack of consensus) ?

We can retrofit 1.0.x easily as a compromise solution in the interim that the rest of the core development team actually meets our specs for design and structure changes so D&A can complete it's stated goal as per the Joomla Mission Statement to the best of its abilities.

In regard to what Andrew Eddie suggested, I think that it has been implemented (in the front end, not the backend, yet), if I understand what you are saying.  I tried to point out in one of my earlier posts that all of the functional logic for a front end component in the 1.5 core has been separated from the actual rendering logic.  Hopefully, I can illustrate this point a little bit better.  In 1.5, components are broken up into several pieces, the two most relevant to this conversation are Models and Views.  A model is class that contains/controls the functionality for how the component does what it does, functionally.  For example, if my component needs to save something in a cookie, it would to that inside the Model.  On the other side of that is a View.  A View is best understood in two parts (this is just my opinion), the first part of the view does a little bit of logic in interaction with the Model, so, if my component fetches information from the database, it will store it in an object/array/var/whatever inside the Model, then, the View has to get that information out of the Model so it fetches the Model and then takes whatever item out of it that you want, and puts it in the Views scope.  Once all of that is done, we get to the really nice part about 1.5 and something that I think you will like. 

I already discussed this at length when MVC first went live (as I've been tracking it via SVN) and the profound problems with the direction the core has taken to implement CMP-dependent MVC structures instead of device agnostic, ubitiqious MVC structures that then can be used to build each CMP independently. The core, by taking this coding path, in no way acknowledges the problems faced by D&A, and as such makes our live harder instead of easier..

When you have 80% of the D&A team itself saying we want no more hacks in order to make J! accessible, why aren't you guys listening?

The view will include a separate file that contains nothing but the display logic.  Depending on the format requested (HTML, RAW, PDF, etc.) there will be a separate file, and the really awesome part about this whole thing is that a template, like your standard template packages, can override this and call a display logic file of its own!  Isn't that great?  I think it is awesome! 

The fatal flaw is still CMP dependence, and as such, amounts to the same version control issues in 1.5 that we have in 1.0. Sorry, but that just shows how much the core development isn't listening or doesn't want to listen to D&A and the solution we've found to not only solve our dilemma, but also the dilemmas of:
1) Not every core CMP being accessible
2) 3PDs not generating compliant code when building for J!.

The solution we offer meets our goals as part of the Joomla Mission Statement perfectly. Now why won't you allow us to meet that goal?

All of the HTML (for example) is kept in this one file for that one format and the file to open, instead of the default, can be overridden by a template.  It is a great system that I am really just learning the power of but I have to say, it opens up a lot of options that were not available in 1.0.

It may be great to you, but it's still not device agnostic, nor is the styling able to be ubitiqious across the entire CMS for that view, so whatever CMP using that view that automatically gains those benefits..

[Jenny]

2) 3PDs not generating compliant code when building for J!.

This is not a Joomla! issue.  The core cannot and should not control or try to control what 3PDs do.  This is aspect does not belong in this discussion of what needs to be done to the J! core.

[brian]

no but I guess they can lead the way

[Jenny]

no but I guess they can lead the way

I am all for the core of Joomla! to be an example to lead 3PDs to greatness.  I think that to incorporate the necessary changes in the core to meet the BASIC standards of accessibility, the discussion has to stop from getting muddled by external unnecessary factors and a tendency to promote a "more is better" platform.  This is what is stopping accessibility solutions from moving forward.

If in the core of Joomla! the basic standards are met, that should then open up the way for quality extended accessibility solutions to be developed, and should also allow for better quality in (terms of standards) extensions in general.

[absalom]

This is not a Joomla! issue.  The core cannot and should not control or try to control what 3PDs do.  This is aspect does not belong in this discussion of what needs to be done to the J! core.

But it damned well can educate them and make it simpler for 3PDs to generate accessibility compliant code interfacing with J!.

The solution D&A have been advocating for the last year solves the problem of not all core CMPs being accessible out of the box. An added bonus is that same device agnostic, ubitiqious, extensible template-based framework can be used by 3PDs as they end up using the same process the core will be using to develop.

[absalom]

I am all for the core of Joomla! to be an example to lead 3PDs to greatness.  I think that to incorporate the necessary changes in the core to meet the BASIC standards of accessibility, the discussion has to stop from getting muddled by external unnecessary factors and a tendency to promote a "more is better" platform.  This is what is stopping accessibility solutions from moving forward.

Then you're not getting it in the same way Johan and the rest of the core development team aren't getting it.

The consensus across the D&A team is that hacks are not worth it. Considering how far the SVN has actually multiplied complexity for CMP development on the 1.5 trunk, instead of creating "simpler" hacks to solve wider problems, 1.5 amounts to more complex hacks than 1.0 to simply solve the same problems. This is a flagrant waste of resources. Hell, even eyeberg recognises this..

The solution we have been proposing in various forms since J! first went live (even when Nic was part of the core) is that accessibility be a primary core process and that every CMP developed, either by the core or by anyone else, can interface to that process and gain those benefits. Accessibility is an underlying principle, it has to be in order for everyone to benefit from it, not an addon or an afterthought.

The only thing stopping accessibility moving forward is the lack of consensus from the core team in regards to how they deal with the solutions D&A provide. We've had the solution for a while now. Nobody else is damned well doing anything about it. There have been 2 (yes, that's right - 2!!!) Google SOC J! accessibilty projects that went in divergent directions away from what the entire D&A/U&A team have recommended and neither of the SOC projects provided any deliverables. We have a functional spec as to what needs to happen. We know where that spec should be implemented and how it affects CMP development.

If in the core of Joomla! the basic standards are met, that should then open up the way for quality extended accessibility solutions to be developed, and should also allow for better quality in (terms of standards) extensions in general.

But that still leaves D&A churning out hacks.. and since D&A are all in agreement that hacks are bad, especially when the solution we recommend meets the stated Mission Statement goals perfectly, who needs to accomodate ?

Let me put it this way:

Is the Mission Statement given to U&A/D&A wrong, and if so, why ?

[Jenny]

No .. it is you who doesn't get it Lawrence... you are so stuck on what you believe.. that you can't see out of that into something bigger than you.

Think out of the small box you want to put Joomla! into.. your personal box..


If you can't do that .. then you are the one that doesn't understand.. not I, my friend.

[Casey Lee]

no but I guess they can lead the way

Very true indeed. We *do* have a clean slate before us. The best we can do is take it very seriously so it will be taken seriously by the 3PD community. If there's hand-holding involved then that is a small price to pay. I can't begin to count how many accessible templates I've made that are virtually useless due to sloppy 3PD code. Will we have the same problem with 1.5 in another year? I recently supported an (unnamed) component with 130 something open tags. I don't think we want to attract this type of coder at all do we?

$0.02

[absalom]

Very true indeed. We *do* have a clean slate before us. The best we can do is take it very seriously so it will be taken seriously by the 3PD community. If there's hand-holding involved then that is a small price to pay. I can't tell you enough how many accessible templates I've made that are virtually useless due to sloppy 3PD code. Will we have the same problem with 1.5 in another year? I recently supported an (unnamed) component with 130 something open tags. I don't think we want to attract this type of coder at all do we?

$0.02

Well, if you don't give the 3PDs more than just hand-holding and instead some significant buy-in, do you even think they care about getting educated as to fixing the problem ?

[Casey Lee]

Well, That was my point. The hand-holding would not be served as a mere option but as an available guide to putting your components on the Joomla! map at all. If they don't work and it comes back to accessibility then we simply say "fix your code".

Maybe registered 3PD's having access to a forum of registered D&A support?

Perhaps this could lead to a solution from which this thread was started (commercial grievances)?

Joomla! could use this to the advantage of the community, and its 3PDs by offering itself as an accessible CMS.
Those who comply to Joomla! and web standards are given a "certification" badge of sorts stating that they abide by Joomla! quality standards such as:

*answering their forum posts in a timely fashion
*resolving critical security issues and bugs in X amount of days
*abide by accessibility standards.
* etc. etc..

The advantages are endless not only promoting quality but first choice business to those who simply do a good job. Maybe I'm getting ahead of myself here. Just thinking aloud. Seems a lot of bitching in this thread to be so far from any direction for solution.

[absalom]

Well, That was my point. The hand-holding would not be served as a mere option but as an available guide to putting your components on the Joomla! map at all. If they don't work and it comes back to accessibility then we simply say "fix your code".

Which then makes it a core process / ideology that accessibility matters. Unfortunately, Nic and others are not welcome to voice that line of thought round here, and have be punished and censored for attempting to inform people of that fact.

Hand-holding itself isn't enough, for we've had the WCAG / WAI guide that direct core and 3PD components, modules and plugins for a while now (thanks to Nic, again) here: http://help.joomla.org/content/view/806/163/ . Sure, it's the most popular article after the accessibility statement itself on the online manual, but the quality of work that is being churned out in core and 3PD work currently is heading towards eye-candy (e.g. AJAX come what may) over well formedness and excellent design as part of the SDLC. So it's obvious people aren't listening and aren't caring, even with the hand-holding documentation available.

Maybe registered 3PD's having access to a forum of registered D&A support?

Probably not that helpful, as then the D&A team will potentially get saturated with D&A wannabes who market their work as 'accessible' when it's not (which was part of the topic that started this thread).

Perhaps this could lead to a solution from which this thread was started (commercial grievances)?

This thread was started to see how much and to what extent accessibility was a buzzword to the core in comparison to it being something that mattered to people, affecting people in real situations and circumstances. This wasn't about commercial grievances by any means.

See, if all people do is pimp their sites on Sitescore (or any other mechanical validation tool they put their marketrioding in) that they're at the top of the queue without understanding what accessibility actually is, they are no better than sploggers. They are essentially saturating the wider web industry with the false belief that the work they churn out is accessible, when it isn't. And the Core team is at significant risk of falling into the same trap with the CMS itself thanks to the overrides "template pack". Should the Core fall into the same trap?

Joomla! could use this to the advantage of the community, and its 3PDs by offering itself as an accessible CMS.

It could, but it won't. Override hack for 1.5 is no different to the hit and miss we have currently in 1.0.x. It's the same solution people do currently, but in a different area. It doesn't in any way leverage any benefit to 3PDs in their work, and more often than not, only deals with certain processes within the core, not the overall architecture, design and structure of the CMS.

Those who comply to Joomla! and web standards are given a "certification" badge of sorts stating that they abide by Joomla! quality standards such as:

*answering their forum posts in a timely fashion
*resolving critical security issues and bugs in X amount of days
*abide by accessibility standards.
* etc. etc..

Certification in this remains a significantly grey area. Why is this so ?

Any checks for accessibility need to have significant human involvement and ongoing testing. Merely passing a validator (or the shiny red button of Sitescore) isn't enough. And since the core is not primarily involved in delivering those standards, as they have said publically: "This awareness made us shift strategy from ‘putting it all in the core’ to ‘making sure designers can do it themselves’ ", it wouldn't be up to the rest of the J! team to set the standards. They have said don't want to be involved, as they've handballed all responsibility for accessibility to the "designers" who supposedly can do it themselves.. That's just asking for trouble as it doesn't help the designers in any way. The only thing the designers have is the WAI help that Nic wrote, and they don't understand that. They're designers, not coders.

The advantages are endless not only promoting quality but first choice business to those who simply do a good job.

The real benefit in order to get buy-in so 3PDs develop to accessible standards is to make the solution to accessibility device agnostic (core + 3PDs use the same code to get the same benefit, with minimal code reuse all round and easy code to deal with), ubitiqious (so that it works anywhere) and extensible (as people have have different needs for accessibility / standards change over time). A 'good job' may be a relative sliding scale as people may consider those who rate high on Sitescore or any other mechanical 'accessibility' tool good based on false pretences (and/or the ability by those people to game the mechanical tool).

Maybe I'm getting ahead of myself here. Just thinking aloud. Seems a lot of bitching in this thread to be so far from any direction for solution.

Yes, well, I've tried convincing the core numerous times over the last 3 years to the advantages of it, but since they've adopted an ironclad political stance of letting the 'designers' do it themselves, I can't exactly be overjoyed at the possible consequences coming out of that action. In no way does this detract from the skills and abilities of the J! teams, it's just I can see it ending very badly, very quickly for a lot of 'accessibility' players in the J! marketplace, and maybe the Core as well, if they don't get their act into gear.

[eyezberg]

A 'good job' may be a relative sliding scale as people may consider those who rate high on Sitescore or any other mechanical 'accessibility' tool good based on false pretences (and/or the ability by those people to game the mechanical tool).

You can't "game" such a tool, either the code complies to the tests and it passes, or it doesn't.
The value of the rating might be something else, but mechanical tests are simply based on certain criteria which you either comply to or not.
That's why I removed Phils banners and ajax bot from my site, because both don't. Simple as that.

[Asphyx]

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.

Lawrence this is the problem the crusade for accessability is having....
What does and does NOT comply is an OBJECTIVE opinion not a technical certainty!
As you have said time and time again just because it passes a technical test as being accesible it does not mean it really is!
the standard is ambiguous and dependent on human objectivity before it can truly be defined!

And that is why it is so difficult for anyone to make it the ONLY way to code because each different interpretation by a human leads to a different definition of what fits the standard and what does not!

Add to it the standards are so limited in what they alloow that it is almost impossible to comply without throwing away all emerging technology created after 1999 when WCAG 1.0 was adopted, This is never going to work or be supported by the masses!

a subjective standard can never be standardized as it requires a prejudgemental opinion going into the evaluation!

And sometimes that opinion is going to be I don't care about how accessible it really is!

Now Joomla is working to make a more standards accessible system for those that want it.
Just because it isn't happing for you this month should not be a reason to make a post a week demanding that it be included in J!1.5!
It will be in J2.0

Maybe if the standards you insist upon were well defind without the need for human interpretation the job would be easy enough to implement!
But even if the core of J! had the ability to pass every technical test you could think of the bottom line is the test will easily fail if the user who is in control of the tools does not understand exactly how to use those tools!

And because of the human objectivity your standards will not be a standard until one human's objectivity is selected AS the standard methoid of objectivity!

you don't really have a standard you have a guideline that requires subjectivity to be defined and that makes it quite impossible to implement quickly because the core has to implement tools to support all of the different subjective OPINIONS on what meets the standards and what does not!

I still think the job is better done by telling the accessability browsers to deal with any and all code instead of your chosen method of making all code simplistic enough to work on accessible browsers and if any technology can not be simplified for them it should be avoided at all costs!

If it is so easy to change code to make a Java App accessible then it should be easy to get a browser to see the java and spit out the accessible output from it!

[absalom]

You can't "game" such a tool, either the code complies to the tests and it passes, or it doesn't.
The value of the rating might be something else, but mechanical tests are simply based on certain criteria which you either comply to or not.
That's why I removed Phils banners and ajax bot from my site, because both don't. Simple as that.

You can. The fact those sites that deal in 'spam' through certain channels rate higher than the semantically designed (e.g. 2-spyware would be a prime example) merely due to 'reach' (marketing of various forms).. This problem was in spades on the previous edition of Sitescore, but they've fixed it up a bit with the latest edition.

Any mechanical tool can be abused to portray acceptance for something it's not, because it is mechanical.

[absalom]

Lawrence this is the problem the crusade for accessability is having....
What does and does NOT comply is an OBJECTIVE opinion not a technical certainty!

But you can work around that by providing an extensible, device agnostic solution. That allows objectivity on the part of human interaction / usability needs, and it also allows the code to do whatever it needs to get the output required to meet those human needs.

As you have said time and time again just because it passes a technical test as being accesible it does not mean it really is!
the standard is ambiguous and dependent on human objectivity before it can truly be defined!

No, Asp, the standard isn't ambigious, however it is dependent on human behaviour and interaction. My point was merely claiming accessibility and delivering them are two different things. Heck, the CMS has been able to pass Section 508 / WAI A mechanical testing since Mambo 4.5.1 days, but does that mean it actually meets 508 / WAI A ? No.

Do not rely on mechanical testing alone. They are a start, but not to be relied on (same with the shiny red button of Sitescore). Mechanical tests can get it wrong with a greater margin for error than any human interaction.

And that is why it is so difficult for anyone to make it the ONLY way to code because each different interpretation by a human leads to a different definition of what fits the standard and what does not!

Again, extensibility within the design solves that problem. Merely having different intepretations and different standards doesn't in any way lessen the gravity of the problem. It just means you need to make the solution extensible enough to cover those intepretations and standards.

Add to it the standards are so limited in what they alloow that it is almost impossible to comply without throwing away all emerging technology created after 1999 when WCAG 1.0 was adopted, This is never going to work or be supported by the masses!

You'd be wrong on that. I recognise I'm part of a minority in the web industry, but I'm clued in and willing and able to educate anyone as to what is needed to get their sites / CMS / products in order. Educational information has been around since at least 2002/2003 (which A List Apart first went CSS) and there is significant resources available online if the developers / coders ever want to learn what the need to do.

a subjective standard can never be standardized as it requires a prejudgemental opinion going into the evaluation!

Extensibility and device agnosticism take care of both those factors. Extensibility provides the interface to deliver any objective/subjective standard and device agnosticism allows that standard (whatever it is) to be standardised across a product, including potentially into the 3PD development as well.

And sometimes that opinion is going to be I don't care about how accessible it really is!

I know. When you say this, you are pretty much telling me that most other players in the web industry don't want to care about it. This opinion is by no means new or novel to me. I've heard it all before.

That means, in order for you to buy into accessibility, it has to be delivered to you in a way that benefits you, without making you think long and hard about it, right ? From a developers perspective, this means the code has to remain the same.. (or at least so transparent so you don't recognise the output of your work will turn out to be accessible)

Now Joomla is working to make a more standards accessible system for those that want it.

But what about those who need it, and remain unable to use it because of the choices made further up the development arc?

Just because it isn't happing for you this month should not be a reason to make a post a week demanding that it be included in J!1.5!

I'm not demanding. I've mapped out all the possible consequences of 1.5 as it stands, and some of them don't look good, either for 3PDs or for Joomla. I have been approaching this issue through caveat emptor in regards to the overpitched claims by the Core.

Maybe if the standards you insist upon were well defind without the need for human interpretation the job would be easy enough to implement!

Again, there are ways through this sort of dilemma.

But even if the core of J! had the ability to pass every technical test you could think of the bottom line is the test will easily fail if the user who is in control of the tools does not understand exactly how to use those tools!

That's why you let the accessibility experts deliver the semantic model to whatever specification, the developers (Core and 3PDs) use that semantic model in their products, and the end user gets the benefits in all areas of the product (core + 3PDs).

And because of the human objectivity your standards will not be a standard until one human's objectivity is selected AS the standard methoid of objectivity!

you don't really have a standard you have a guideline that requires subjectivity to be defined and that makes it quite impossible to implement quickly because the core has to implement tools to support all of the different subjective OPINIONS on what meets the standards and what does not!

Again, solved by extensibility. Extensibility alllows accomodation of multiple standards, including if and when those standards change. In no way am I recommending the core develop accessibility itself, just the means for accessibility and a truly semantic web to be leveraged.

I still think the job is better done by telling the accessability browsers to deal with any and all code instead of your chosen method of making all code simplistic enough to work on accessible browsers and if any technology can not be simplified for them it should be avoided at all costs!

If it is so easy to change code to make a Java App accessible then it should be easy to get a browser to see the java and spit out the accessible output from it!

Anything done client side is bad (e.g IE quirks mode). Server side management is always a better solution, as you're not taking someone's poorly formed / bad code and attempting to manipulate it into something good. Server side allows you to define, distribute and reuse, with minimal overhead to the client side as all they see is the final output.

[Jenny]

And who would an accessibility expert be?  According to a lot of articles all over the web, even the so called experts can't agree on what is "right" and what is "wrong".