Yes, I'm thinking just the basics: keyboard accessibility, alt tags for images, hidden ways to jump to main content that screen readers can grab (if we ever need that, but probably don't right now), etc.
I'm pretty sure I don't want to know what California's requirements are. ;-) We should be setting the same example for our login page as we update that look and feel. On Wed, Jan 4, 2012 at 1:48 PM, Jacob Lichner <jlich...@unicon.net> wrote: > Well, there's accessible and then there's California-government accessible > if you know what I mean. If we have the latter in our sights, we will also > consequently go broke and slowly sink into the ocean as well... haha :) > > Simply aiming for keyboard accessibility would put us 85% of the way there > and I think would be an excellent place to start. > > > > > ----- Original Message ----- > From: "Scott Battaglia" <scott.battag...@gmail.com> > To: cas-dev@lists.jasig.org > Sent: Wednesday, January 4, 2012 11:07:12 AM > Subject: Re: [cas-dev] CAS-1013 implicit evaluationOrder in service > registrations > > To be as accessible as possible (and yes, I know we have a long way to go > :-)). > > > I know Fluid's components were accessible out of the box. Wasn't sure > about the jQuery plugin (I've found that some are friendly, and some are > not so friendly) > > > At this point where we can make it friendly with minimal effort (and where > it would difficult for someone to work if we didn't), we should just do it. > > > If we need to formalize that, I can certainly propose something. I can > start to put together a guide also (but I would imagine you guys probably > know more than I do) > > > > On Wed, Jan 4, 2012 at 1:07 PM, Jacob Lichner < jlich...@unicon.net > > wrote: > > > > > Yeah definitely because jQuery itself is accessibility-friendly via > various keyboard plugins, etc. > > > What are the accessibility requirements for CAS, exactly? > > > > > > > On Jan 3, 2012, at 5:13 PM, Scott Battaglia wrote: > > > > > Is the jquery one accessibility-friendly? > On Jan 3, 2012 7:03 PM, "Jacob Lichner" < jlich...@unicon.net > wrote: > > > Good discussion. > > (By the way, just got back from a nice break, hope everyone had a great > Christmas and New Year!) > > I am fully on board with Andrew's thoughts here and I believe it was > myself asking that exact question (ie "what can I take away?") that was the > reason behind this particular ticket. It was my original thought after > looking over the UI that the evaluationOrder should take care of itself as > you would expect it to, but there are many factors involved that I am not > aware of. > > I've looked over Misagh's drag and drop implementation and spoke with him > about it today as well, which I would like to repeat here. I want to > suggest sticking with jQuery for the drag and drop rather than Fluid > Infusion. My impression with Fluid is that there is a lot of cumbersome > overhead that adds complexity, creates a steep learning curve, etc (all of > the things you would expect with a cumbersome overhead…). I also asked Matt > and the others if they felt the same way and they feel exactly the same > way. They suggested jQuery Sortable, which is part of the Widget Factory: > > http://jqueryui.com/demos/sortable/ > > (Quick side note: the new skin I created no longer uses FSS as well > because simple CSS is all that is needed, but the new skin is another topic > that I hope to address soon.) > > > > On Dec 20, 2011, at 6:32 AM, Andrew Petro wrote: > > > Misagh, > > > > I hear you on ways to make evaluationOrder more understandable, by > reflecting it in the UI (ability to list in order of evaluationOrder, > display the evaluationOrder attribute with the registrations listing in the > manage view). > > > > My thought is that Order is just not the right abstraction here. The > current services management / services registry solution is using > abstractions that are too abstract versus what would be sufficient. > > > > I expect that CAS adopters don't want more than a few overlapping > patterns, and in the case where patterns do overlap, there are obviously > more specific and less specific patterns, and they always want the more > specific pattern to match. Getting to a programmatic algorithm for > evaluating "obviously more specific" is an interesting nugget of a problem; > I'll be interested to see how solvable this is. I admit I haven't given it > enough thought to to know the answer offhand. > > > > Consider a typical use case. > > > > A university balancing privacy and agility in SSO integrations might > want: > > > > 1) By default, any service may get a persistent, anonymous, opaque > identifier > > 2) All services at https://portal.someschool.edu may get proxy tickets, > since they're service URLs representing portlets that proxy to interesting > other services > > 3) Specific registered services may get the username and, varying by > service, other user attributes > > > > Now, suppose I go and register > > > > https://portal.someschool.edu/NetReg/login > > > > because someone decided to deploy the NetReg application into the > uPortal Tomcat. It's not a portlet, I don't want it getting proxy tickets, > but I do want it to get some other attributes, say. > > > > So, isn't it obvious that I'd want the > https://portal.someschool.edu/NetReg/login registration to supersede the > https://portal.someschool.edu/** registration? > > > > *There's no use case for unreachable registrations.* I certainly don't > want to add the NetReg registration and have it have no effect. And I > certainly don't want to add the registration, have it have no effect, and > not be warned about this. Yes, I could take care in making my registration > have the right evaluationOrder to get the desired effect, and yes, UI > affordances could make it easier to take this care, but I'm wondering if > the best UI affordances around evaluationOrder would be not to have it at > all. > > > > That is, services registry and services management has more in common > with a rules engine and less in common with a Netflix queue. I'm not > queueing discs to be shipped to me, where Order and a better UI for > reflecting and managing Order makes sense, since we're essentially talking > about objects that necessarily really have an order. Rather, we're talking > about rules for how CAS is going to treat a service URL presented at > runtime. These rules have order only incidentally, because computers can > only evaluate them serially and because this is how logic works. They're > not inherently ordered. evaluationOrder isn't reflecting something inherent > about the domain -- it's a concession to the implementation. > > > > So, it seems to me that the use cases for these registrations are > simpler than the arbitrary configuration that evaluationOrder supports. I > don't need the power to create registrations with relative evaluationOrder > such that in practice they will never have any effect. Can I have less > power and more usability? > > > > If evaluationOrder had never existed, how would CAS figure out which > registration matches, and would that be good enough? > > > > I can't imagine a CAS deployment with more than 1000 service > registrations. Might it actually be true that CAS could load all > registrations into memory, *try every one of them*, and pick the one with > the most specific pattern that matched? I'm not saying that's the right, > refactored, quality algorithm to use here. But might it be the "simplest > thing that could possibly work", and might it be more usable than what's > there now? > > > >> if order really has to go away > > > > I don't think of it this way. This isn't a war on "evaluationOrder". > Order doesn't really have to go away, or really have to be there. It's less > a question of what has to go away, and much more a question of what has to > be there. > > > > Isn't there some adage about a design being complete not when everything > that's needed has been added, but rather when everything that is not needed > has been taken away? > > > > My thought is that evaluationOrder isn't needed here, and can be taken > away, and the result will be simpler and better, if it proves feasible to > program the intuition of which registration "obviously" should match when > two overlap. > > > > Kind regards, > > > > Andrew > > > > PS: Thought: Perhaps evaluationOrder remains as an internal > implementation detail, derived from the registrations and precompiled on > registry edit. > > > > On Dec 19, 2011, at 4:11 PM, Misagh Moayyed wrote: > > > >> Folks, > >> > >> Started to evaluate this new CAS feature request: > https://issues.jasig.org/browse/CAS-1013 > >> > >> Few thoughts: > >> > >> 1. I would imagine that setting up a basic numeric value to indicate > order would be much easier to understand than regular expression patterns. > I certainly would be in favor of the property, but what I find confusing is > that services management UI does not list the registered services by their > order, but sorts them using their name. I think this is pretty misleading > because you could have service A up at the top with the order 999999 and > the user would probably assume that just because it comes first, it gets to > be evaluated first as well. I think it’d be better if we modify the UI to > sort by evaluation order > >> > >> 2. Why not show the value of the order on the UI in the list of > services ? The scenario would be that if I want to register a new service, > wouldn’t it be easier to know what the order of the new service should be > beforehand rather than going back and forth between previously registered > services and trying to find what the order should be based on other > services? As the original comment on the feature says, if it’s on the main > services page, it would be a better reminder for it to be updated. > >> > >> 3. I have also looked at ANTLR to see if an existing algorithm already > exists. So far, haven’t found any other alternative. So, for starters if > order really has to go away, how about something like the following > priority order: > >> > >> a. Non-pattern URLs > >> b. Longer URLs > >> c. Prefer URLs that use “?” over those that use “**” or “*” > >> > >> Suggestions are welcome. > >> > >> -Misagh > >> > >> > > > > -- > > You are currently subscribed to cas-dev@lists.jasig.org as: > jlich...@unicon.net > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > jlich...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > jlich...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
