myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Date Thu, 20 Dec 2012 15:42:45 GMT
I agree with Werner.

On Thu, Dec 20, 2012 at 2:37 AM, Werner Punz <werner.punz@gmail.com> wrote:
>
> 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