+1 The benefits outweigh the overcrowding of attributes, in my opinion.
On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe <lu4...@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.p...@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.
