myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Date Sat, 22 Dec 2012 03:22:09 GMT
Hi Werner, 

Now I am not sure which is better. Tag soup or attribute soup ;)

Best regards, 

Martin

Am 20.12.2012 um 08:37 schrieb Werner Punz <werner.punz@gmail.com>:

> 
> I am not sure if it really makes sense to offload attributes into separate tags unless
they are common to more than one component.
> Aka styleClass and style yes, currentDayCellClass etc... definitely not it 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 tag 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:
>> 
>>             <t:inputCalendar id="secondOne"
>> monthYearRowClass="yearMonthHeader" weekRowClass="weekHeader"
>> popupButtonStyleClass="standard_bold"
>>                 currentDayCellClass="currentDayCell"
>> value="#{calendarBean.secondDate}" renderAsPopup="true"
>>                 popupTodayString="#{example_messages['popup_today_string']}"
>>                 popupDateFormat="MM/dd/yyyy"
>> popupWeekString="#{example_messages['popup_week_string']}"
>>                 helpText="MM/DD/YYYY"/>
>> 
>> to something like this?
>> 
>>             <t:inputCalendar id="secondOne"
>> value="#{calendarBean.secondDate}" renderAsPopup="true"
>>                 popupDateFormat="MM/dd/yyyy"
>>                 helpText="MM/DD/YYYY">
>>                     <t:styleAttributes monthYearRowClass="yearMonthHeader"
>>                                               weekRowClass="weekHeader"
>> 
>> popupButtonStyleClass="standard_bold"
>> 
>> currentDayCellClass="currentDayCell"
>> 
>> popupTodayString="#{example_messages['popup_today_string']}"
>> 
>> popupWeekString="#{example_messages['popup_week_string']}" />
>>             </t:inputCalendar>
>> 
>> Or maybe this:
>> 
>>             <t:inputCalendar id="secondOne"
>> value="#{calendarBean.secondDate}" renderAsPopup="true"
>>                 popupDateFormat="MM/dd/yyyy"
>>                 helpText="MM/DD/YYYY">
>>                     <t:styleAttributes
>> value="#{styleAppScopeBean.calendarPropertyMap}"/>
>>             </t:inputCalendar>
>> 
>> 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 <cagatay.civici@gmail.com>:
>>> 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 <mmarinschek@apache.org> wrote:
>>> 
>>> Hi guys,
>>> 
>>> 
>>> Wdyt?
>>> 
>>> best regards,
>>> 
>>> Martin
>>> 
>>> 
>>> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <grant@marathonpm.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> The benefits outweigh the overcrowding of attributes, in my opinion.
>>>> 
>>>> 
>>>> On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe <lu4242@gmail.com>
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 <werner.punz@gmail.com>:
>>>>>> Ok just to be more precise, I have integrated the changes now locally,
>>>>>> but I
>>>>>> am not committing them yet, because it would mean to introduce another
>>>>>> 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 inline
>>>>>> 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
suggestion
>>>>>>>> on
>>>>>>>> how to make the Tomahawk Calendar more WCAG compliant.  WCAG
being a
>>>>>>>> standard for gauging if browser based interfaces meet accessibility
>>>>>>>> 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 ‘alt’ and ‘title’ attributes
on tags
>>>>>>>> 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 – I didn’t do the
compliancy
>>>>>>>> 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’t say it would
be fully
>>>>>>>> compliant.
>>>>>>>> 
>>>>>>>> The properties with hopefully self-describing names are:
>>>>>>>> 
>>>>>>>>          calendarIconAlt
>>>>>>>> 
>>>>>>>>          popupLeftArrowAlt
>>>>>>>> 
>>>>>>>>          popupRightArrowAlt
>>>>>>>> 
>>>>>>>>          popupMonthArrowAlt
>>>>>>>> 
>>>>>>>>          popupYearArrowAlt
>>>>>>>> 
>>>>>>>>          popupCloseButtonAlt
>>>>>>>> 
>>>>>>>>          popupWeekOfYearTitle
>>>>>>>> 
>>>>>>>>          popupWeekOfDateTitle
>>>>>>>> 
>>>>>>>> I’ve 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 ( they
>>>>>>>> seemed to have got a newer version of the js file and made
the
>>>>>>>> changes
>>>>>>>> on it but I can’t figure out which version get got it from,
probably
>>>>>>>> obvious to you guys).
>>>>>>>> 
>>>>>>>> A related change is also included and was made because part
of WCAG
>>>>>>>> is
>>>>>>>> supporting screen readers.  The text in alt and title attributes
>>>>>>>> shouldn’t 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
(they
>>>>>>>> only
>>>>>>>> contained changed methods and have “WCAG change” 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 see
>>>>>>>> how
>>>>>>>> the new properties and full week name array are used.  There
may be
>>>>>>>> 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
> 
> 

Mime
View raw message