From dev-return-60537-apmail-myfaces-dev-archive=myfaces.apache.org@myfaces.apache.org Thu Dec 20 15:43:32 2012 Return-Path: X-Original-To: apmail-myfaces-dev-archive@www.apache.org Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 74C17D187 for ; Thu, 20 Dec 2012 15:43:32 +0000 (UTC) Received: (qmail 97428 invoked by uid 500); 20 Dec 2012 15:43:32 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 97387 invoked by uid 500); 20 Dec 2012 15:43:32 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 97379 invoked by uid 99); 20 Dec 2012 15:43:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Dec 2012 15:43:32 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mkienenb@gmail.com designates 209.85.212.175 as permitted sender) Received: from [209.85.212.175] (HELO mail-wi0-f175.google.com) (209.85.212.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Dec 2012 15:43:27 +0000 Received: by mail-wi0-f175.google.com with SMTP id hm11so4415339wib.8 for ; Thu, 20 Dec 2012 07:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=1+RrMCzwwVs0WCiVpE3fnx49Gs8IzDFD3/ZAUR1iA20=; b=mh/e4rM+1tWuSpLceSCpoFY8JAxTmSTHnnIFaj8Hh4uLdTNXC345mX5+HdvwEDRTZl fvq/XV/XXrRYt5p09ab5pVFg+bqBVXTsVAyS6cxtP29Xpoe/R9BCcVSXfkvkWYk5y9sK tdYWM/utMW8IWPWaINk4AFVAL6wiXFn3Jc3ZjQZ6Lv8hwBaI49c+sX4l9+ZrZa6t/pWD YPzTO56uLTl8LZODj6wqbFLk7KQPjwtpHyVWmuVCPIfE1WvrPu3rqmnRJ/38t5QFmN/i VEDtj10/CbtGsf6pTi71TY2ZtteXXp86cptaBWOyeqOgvOUm/0bEvm1Ii9m5tS+xn2kY u7/w== Received: by 10.194.143.35 with SMTP id sb3mr18307961wjb.30.1356018186302; Thu, 20 Dec 2012 07:43:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.28.161 with HTTP; Thu, 20 Dec 2012 07:42:45 -0800 (PST) In-Reply-To: References: <-7138576298441306450@unknownmsgid> From: Mike Kienenberger Date: Thu, 20 Dec 2012 10:42:45 -0500 Message-ID: Subject: Re: Making Tomahawk Calendar more WCAG (accessibility) compliant To: MyFaces Development Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I agree with Werner. On Thu, Dec 20, 2012 at 2:37 AM, Werner Punz wrote: > > I am not sure if it really makes sense to offload attributes into separat= e > tags unless they are common to more than one component. > Aka styleClass and style yes, currentDayCellClass etc... definitely not i= t > does not make sense to introduce a tag where an attribute suffices, > otherwise we will end up with something like the Maven syntax which is a = tag > soup par excellence. > > So I am not opposed to the idea (probably as Leo said, could be done > generically with a tagHandler) > > But I dont see a usecase for our WCAG extensions here, which are calendar > specific. > > > Werner > > > > Am 19.12.12 22:01, schrieb Leonardo Uribe: > >> Hi >> >> MM >> I had the idea once that one could have an extra embedded style ta= g >> which >> MM >> goes with each one of the extended components. So you could >> embed this tag, >> MM >> and set the style attributes there, and the main component would >> stay clean. >> >> To be more specific, the idea could be move the code from this: >> >> > monthYearRowClass=3D"yearMonthHeader" weekRowClass=3D"weekHeader" >> popupButtonStyleClass=3D"standard_bold" >> currentDayCellClass=3D"currentDayCell" >> value=3D"#{calendarBean.secondDate}" renderAsPopup=3D"true" >> >> popupTodayString=3D"#{example_messages['popup_today_string']}" >> popupDateFormat=3D"MM/dd/yyyy" >> popupWeekString=3D"#{example_messages['popup_week_string']}" >> helpText=3D"MM/DD/YYYY"/> >> >> to something like this? >> >> > value=3D"#{calendarBean.secondDate}" renderAsPopup=3D"true" >> popupDateFormat=3D"MM/dd/yyyy" >> helpText=3D"MM/DD/YYYY"> >> > monthYearRowClass=3D"yearMonthHeader" >> weekRowClass=3D"weekHeade= r" >> >> popupButtonStyleClass=3D"standard_bold" >> >> currentDayCellClass=3D"currentDayCell" >> >> popupTodayString=3D"#{example_messages['popup_today_string']}" >> >> popupWeekString=3D"#{example_messages['popup_week_string']}" /> >> >> >> Or maybe this: >> >> > value=3D"#{calendarBean.secondDate}" renderAsPopup=3D"true" >> popupDateFormat=3D"MM/dd/yyyy" >> helpText=3D"MM/DD/YYYY"> >> > value=3D"#{styleAppScopeBean.calendarPropertyMap}"/> >> >> >> And move the styling attribute from the markup to an application scope >> bean like >> the proposal in JSF 2.2 related to f:attributes tag?. >> >> I think with just a facelet TagHandler it is possible to do it. Maybe >> have a generic style tag and >> a special style tag for calendar component, because calendar has a lot >> of related attributes. >> >> regards, >> >> Leonardo Uribe >> >> 2012/12/19 Cagatay Civici : >>> >>> Hi, >>> >>> I decided to go with a javascript bundle in PF as calendar is a special >>> component in terms or localization and internationalization. >>> >>> http://code.google.com/p/primefaces/wiki/PrimeFacesLocales >>> >>> Regards, >>> >>> Cagatay Civici >>> PrimeFaces Lead >>> Prime Teknoloji >>> www.prime.com.tr >>> >>> On 19 Ara 2012, at 22:04, Martin Marinschek >>> wrote: >>> >>> Hi guys, >>> >>> >>> Wdyt? >>> >>> best regards, >>> >>> Martin >>> >>> >>> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith >>> wrote: >>>> >>>> >>>> +1 >>>> >>>> The benefits outweigh the overcrowding of attributes, in my opinion. >>>> >>>> >>>> On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe >>>> wrote: >>>>> >>>>> >>>>> +1 >>>>> >>>>> I think the proposal looks good, the names used in the properties are >>>>> ok, >>>>> and >>>>> there is certainty that the changes are useful. >>>>> >>>>> regards, >>>>> >>>>> Leonardo >>>>> >>>>> 2012/12/19 Werner Punz : >>>>>> >>>>>> Ok just to be more precise, I have integrated the changes now locall= y, >>>>>> but I >>>>>> am not committing them yet, because it would mean to introduce anoth= er >>>>>> set >>>>>> of attributes to the Calendar yet. >>>>>> >>>>>> I just want the opinion whether we should do it. >>>>>> Just to give s small description, the attributes would add alt texts >>>>>> to the popup calendar and default alt texts are set anyway, the inli= ne >>>>>> calendar does not have images hence no alt is needed and possible. >>>>>> >>>>>> The downside of this is that we add another set of attributes: >>>>>> >>>>>> popupLeftArrowAlt >>>>>> , popupRightArrowAlt >>>>>> , popupMonthArrowAlt >>>>>> , popupYearArrowAlt >>>>>> , popupCloseButtonAlt >>>>>> , calendarIconAlt >>>>>> , popupWeekOfYearTitle >>>>>> , popupWeekOfDateTitle >>>>>> >>>>>> which is a huge set of new attributes to the already attribute >>>>>> overloaded >>>>>> calendar. >>>>>> >>>>>> So what is your opinion guys, shall we add it or not. >>>>>> I favor for a +1 here, since accessability is a big plus >>>>>> and the new attributes are optional in their usage. >>>>>> >>>>>> Werner >>>>>> >>>>>> >>>>>> >>>>>> Am 19.12.12 11:23, schrieb Werner Punz: >>>>>> >>>>>>> Mhh shall we integrate this? >>>>>>> I personally think it would make sense with some name changes. >>>>>>> >>>>>>> >>>>>>> Werner >>>>>>> >>>>>>> Am 17.12.12 18:54, schrieb Jon Bionda: >>>>>>>> >>>>>>>> >>>>>>>> Sorry for what is likely a breach of protocol. This is a suggesti= on >>>>>>>> on >>>>>>>> how to make the Tomahawk Calendar more WCAG compliant. WCAG being= a >>>>>>>> standard for gauging if browser based interfaces meet accessibilit= y >>>>>>>> requirements primarily for disabled users. I joined the list a >>>>>>>> while >>>>>>>> ago to report an error I found and it was fixed promptly so I >>>>>>>> continued >>>>>>>> to watch the list and see that you are now preparing the next >>>>>>>> Tomahawk >>>>>>>> release, so maybe the timing is right. >>>>>>>> >>>>>>>> We used an older version of Tomahawk (1.0.6) and found the >>>>>>>> HtmlInputCalendar component failed the WCAG compliancy tests with >>>>>>>> respect to missing some =91alt=92 and =91title=92 attributes on ta= gs >>>>>>>> generated >>>>>>>> by the calendar component. Some time ago, someone who has since >>>>>>>> left >>>>>>>> the company, made it mostly compliant by adding the following 8 >>>>>>>> properties to the HtmlInputCalendar =96 I didn=92t do the complian= cy >>>>>>>> testing >>>>>>>> but understand there are different levels of compliancy and these >>>>>>>> missing attributes make it fail at a basic level, so there may be >>>>>>>> more >>>>>>>> minor compliance issues which is why I can=92t say it would be ful= ly >>>>>>>> compliant. >>>>>>>> >>>>>>>> The properties with hopefully self-describing names are: >>>>>>>> >>>>>>>> calendarIconAlt >>>>>>>> >>>>>>>> popupLeftArrowAlt >>>>>>>> >>>>>>>> popupRightArrowAlt >>>>>>>> >>>>>>>> popupMonthArrowAlt >>>>>>>> >>>>>>>> popupYearArrowAlt >>>>>>>> >>>>>>>> popupCloseButtonAlt >>>>>>>> >>>>>>>> popupWeekOfYearTitle >>>>>>>> >>>>>>>> popupWeekOfDateTitle >>>>>>>> >>>>>>>> I=92ve looked into forward porting the old changes to the Tomahawk >>>>>>>> 1.1.14 >>>>>>>> code base and have provided the code for adding the changes to the >>>>>>>> (org.apache.myfaces.custom.calendar) HtmlInputCalendar and >>>>>>>> HtmlCalendarRenderer classes. However, I am having trouble >>>>>>>> unravelling >>>>>>>> the precise changes that were made to the popcalendar.js file ( th= ey >>>>>>>> seemed to have got a newer version of the js file and made the >>>>>>>> changes >>>>>>>> on it but I can=92t figure out which version get got it from, prob= ably >>>>>>>> obvious to you guys). >>>>>>>> >>>>>>>> A related change is also included and was made because part of WCA= G >>>>>>>> is >>>>>>>> supporting screen readers. The text in alt and title attributes >>>>>>>> shouldn=92t be using short forms of the week days (Sun, Mon, etc.)= but >>>>>>>> rather their full names (Sunday, Monday, etc.). In the >>>>>>>> HtmlCalendarRenderer.getLocalizedLanguageScript() method, I see >>>>>>>> where >>>>>>>> they created a parallel String[] to weekDays to contain the full >>>>>>>> week >>>>>>>> day names. This is also added to the initData to be accessible in >>>>>>>> the >>>>>>>> javascript. We only use the calendar in popup mode so no changes >>>>>>>> were >>>>>>>> made to renderInline() but would expect it would also have to be >>>>>>>> modified to do a complete job. >>>>>>>> >>>>>>>> I zipped up the changes to the 2 java classes mentioned above (the= y >>>>>>>> only >>>>>>>> contained changed methods and have =93WCAG change=94 comments >>>>>>>> identifying >>>>>>>> the changes), plus a sample properties file for default values and >>>>>>>> our >>>>>>>> popcalendar.js file. This last one is where my knowledge is >>>>>>>> insufficient to help much, but maybe you will find it useful to se= e >>>>>>>> how >>>>>>>> the new properties and full week name array are used. There may b= e >>>>>>>> other changes in the javascript file too as there was an issue >>>>>>>> related >>>>>>>> to focus. >>>>>>>> >>>>>>>> Thanks for your time and hope this helps. >>>>>>>> >>>>>>>> Jon Bionda >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Grant Smith - V.P. Information Technology >>>> Marathon Computer Systems, LLC. >>>> >>> >>> >>> >>> -- >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >> >> > >