You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2012/12/19 11:23:22 UTC
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
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
>
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Martin Marinschek <ma...@gmail.com>.
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 <we...@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 <ca...@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 <mm...@apache.org> wrote:
>>>
>>> Hi guys,
>>>
>>>
>>> Wdyt?
>>>
>>> best regards,
>>>
>>> Martin
>>>
>>>
>>> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@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 <lu...@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 <we...@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
>
>
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Mike Kienenberger <mk...@gmail.com>.
I agree with Werner.
On Thu, Dec 20, 2012 at 2:37 AM, Werner Punz <we...@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 <ca...@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 <mm...@apache.org>
>>> wrote:
>>>
>>> Hi guys,
>>>
>>>
>>> Wdyt?
>>>
>>> best regards,
>>>
>>> Martin
>>>
>>>
>>> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@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 <lu...@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 <we...@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
>>
>>
>
>
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Werner Punz <we...@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 <ca...@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 <mm...@apache.org> wrote:
>>
>> Hi guys,
>>
>>
>> Wdyt?
>>
>> best regards,
>>
>> Martin
>>
>>
>> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@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 <lu...@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 <we...@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
>
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <ca...@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 <mm...@apache.org> wrote:
>
> Hi guys,
>
>
> Wdyt?
>
> best regards,
>
> Martin
>
>
> On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@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 <lu...@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 <we...@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
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Cagatay Civici <ca...@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 <mm...@apache.org> wrote:
Hi guys,
I had the idea once that one could have an extra embedded style tag which
goes with each one of the extended components. So you could embed this tag,
and set the style attributes there, and the main component would stay clean.
Wdyt?
best regards,
Martin
On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@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 <lu...@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 <we...@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
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Martin Marinschek <mm...@apache.org>.
Hi guys,
I had the idea once that one could have an extra embedded style tag which
goes with each one of the extended components. So you could embed this tag,
and set the style attributes there, and the main component would stay clean.
Wdyt?
best regards,
Martin
On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith <gr...@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 <lu...@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 <we...@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
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Grant Smith <gr...@marathonpm.com>.
+1
The benefits outweigh the overcrowding of attributes, in my opinion.
On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe <lu...@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 <we...@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.
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Leonardo Uribe <lu...@gmail.com>.
+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 <we...@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
>>>
>>
>>
>>
>
>
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Posted by Werner Punz <we...@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
>>
>
>
>