- Brian Richwine - Indiana University
- Mary Stores - Indiana University
- Gonzalo Silverio - University of michigan
- Brian submitted a new patch, taking Gonzalo's comments and applying them to the patch.
- Brian hasn't figured out the internationalization. However, Gonzalo would be willing to help with that.
Reviewing Jira Tickets
- Last Thursday Mary Stores, Joe Humbert and Brian Richwine reviewed jira tickets.
- Some of them require fixes that are quick, so Brian said he can put the ticket in and submit a patch.
- In Profile2, Steve Swinsburg picked up accessibility report and wrote 19 jira tickets for the issues there.
- Gonzalo will pick up Page Order Wiki and Preferences.
- The fix needed for the Page Order Wiki is to have the same text in the alt atribue as in the link.
Solution for select elements
- Brian tested in Opera, Safari Firefox and IE in oSx and Windows.
- Brian rerote it, and aded a namespace to it.
- All the activity takes place in that object. if a person uses the routine where it decides to fire the onchange event when appropriate, in Sakai there's a blur function that takes the focus off the control.
- If a person uses Internet Explorer and XP and they go through a series of select boxes, when they make a chage the focus jumps to the top of the Iframe.
- You then have to tab through the Iframe to get to the next change.
- When Sakai 2.6 came out, onchange event in select items did not trigger onchange when wrapped in a fieldset. that's why the blur function was aded.
- The solution might be to remove the blur because it would be easier to convince someone to remove something that's no longer needed, considering it's four years later, than to add a fairly complex handler. However, this handler that Brian wrote, at least parts of it, may still be used in the future.
- Brian says there are a few cases in tables where there's a list of objects and a select field of how any of them can be displayed,.The pae reloads when trying to select something with the keyboard.
- The blur prevents people from using alt plusdown-arrow.
- A separate jira will have to be written where this occurs. so each tool will have to be tested and verified that this is where the problem occurs.
- Brian will help to see what tools and locations have that issue. Gonzalo will send a list of everywhere the source code happens.
- Brian will begin this Jira process.
- This is the largest keyboard accessibility issue. There are twelve tools.
- The issue involves the previous and next buttons, using < and > The Jira ticket writer requests that words be used instead.
- That the accessibility barrier for screen reader users is that by default, they have punctuation verbosity set to announce few or no punctuation marks. Otherwise, they would hear every punctuation mark on the web page.
- Screen Reader users can use the arrow keys to read the less-than and greater-than signs, but they may have to think about which way the arrow is pointing and then translate that to the Previous and Next buttons.
- The reason words cannot be used in some cases instead of symbols is there is not enough real estate on the screen.
- * A possible fix might be converting it over to a button tag. CSS might be able to be applied. shift part of it off the screen and make it go away.
- In worksite setup in site navigator, those two are input type submit buttons. There would be more resistance to turn those into buttons. by default JAWS doesn't red title atribute, so that is not the best solution.
- Birna and Gonzalo will come up with a list of solutions for this problem from optimal to not so good.
There are still a few patches Brian and Gonzalo have submitted that have not been applied.
- Brian needs to bring those up to Anthony.
- Verify fix has complication.
- Gradebook belongs to IU, so Mary and Brian will speak to Karen Wotkins. Mary and Brian will test the patch to make sure it's fixed.