Just sending out a reminder of the a11y talk that we will have tomorrow at 2pm eastern time.
I'll be trying to set up a skype call; please ensure that I have you as a contact if you would like to participate. Thanks Justin On 2010-08-27, at 1:00 PM, Justin Obara wrote: > I'll try to set up a Skype call for the meeting this coming Wednesday. Could > everyone who would like to join please let me know and make sure that I have > you as a contact on Skype. > > Thanks > Justin > > On 2010-08-26, at 2:22 PM, E.J. Zufelt wrote: > >> Sep 1, and Skype work well for me. I can do Connect / IRC, but it is really >> a sub-optimal experience. >> >> Thanks >> Everett Zufelt >> http://zufelt.ca >> >> Follow me on Twitter >> http://twitter.com/ezufelt >> >> View my LinkedIn Profile >> http://www.linkedin.com/in/ezufelt >> >> >> >> On 2010-08-26, at 2:20 PM, Justin Obara wrote: >> >>> Sorry, about the date. It is September 1, which is the first Wednesday in >>> September. Developer meetings usually happen every Wednesday and usually in >>> connect. However for this meeting I think you are right, we should try to >>> use a different system. Maybe we could try to setup a skype conference call >>> or something. >>> >>> Thanks >>> Justin >>> On 2010-08-26, at 2:10 PM, E.J. Zufelt wrote: >>> >>>> Good afternoon, >>>> >>>> Which Wednesday in Sep? >>>> >>>> Also, I tweeted for standards on inline edit. The only response was from >>>> Steve Faulkner who refered me to the Fluid inline edit :) So, we might be >>>> leading the standardization of inline edit accessibility here. >>>> >>>> Will this be over Connect? Because it is a bit inconvenient to >>>> participate in a conversation where others can talk and I can only type in >>>> the IRC channel. >>>> >>>> THanks, >>>> Everett Zufelt >>>> http://zufelt.ca >>>> >>>> Follow me on Twitter >>>> http://twitter.com/ezufelt >>>> >>>> View my LinkedIn Profile >>>> http://www.linkedin.com/in/ezufelt >>>> >>>> >>>> >>>> On 2010-08-26, at 2:03 PM, Justin Obara wrote: >>>> >>>>> At the next developer meeting, Wednesday Sept at 2pm, I think it would be >>>>> a good idea to talk about these and any other a11y issues that come up on >>>>> this thread. >>>>> >>>>> Does that time work for everyone, or should we schedule a specific >>>>> meeting another time. >>>>> >>>>> Thanks >>>>> Justin >>>>> >>>>> On 2010-08-24, at 4:11 PM, E.J. Zufelt wrote: >>>>> >>>>>> On 2010-08-24, at 3:53 PM, Justin Obara wrote: >>>>>> >>>>>>> Hi Everett, >>>>>>> >>>>>>> This is an interesting topic, I think some of the designers might also >>>>>>> have some thoughts on the interaction too. I'll add some comments in >>>>>>> below. >>>>>>> >>>>>>> Thanks >>>>>>> Justin >>>>>>> >>>>>>> On 2010-08-24, at 1:10 PM, E.J. Zufelt wrote: >>>>>>> >>>>>>>> So, instead using the ARIA button role, can we just provide a text >>>>>>>> link (invisible) before the item with the text "Edit" or something >>>>>>>> more meaningful "Activate edit mode". >>>>>>> >>>>>>> In this case, would you then not focus on the inline editable element >>>>>>> itself to access it. I think this maybe confusing to some users. But >>>>>>> I'm not sure I'm understanding it correctly. >>>>>> >>>>>> I suppose this would be like a "isEditable" link, which sadly isn't in >>>>>> the current xhtml / ARIA API. But, essentially what we are looking for >>>>>> here is a method of clearly identifying that the text can be toggled >>>>>> into a mode in which it can be edited. E.g. >>>>>> >>>>>> <p> >>>>>> <a href="#" class="element-invisible">Click to edit following >>>>>> text</a>Some paragraph text here >>>>>> </p> >>>>>> >>>>>> You could still have the functionality bound to the click or enter on >>>>>> the paragraph, and on the anchor as well. >>>>>> >>>>>> Benefit: >>>>>> >>>>>> Screen-readers don't hear "button" at the end of each segment of text >>>>>> that is clearly not a button. >>>>>> >>>>>> Drawbacks: >>>>>> Sighted keyboard only, and screen-reader, users have one extra tabstop. >>>>>> >>>>>> Clearly the problem here is that we are trying 1. to create behavior >>>>>> that no web standard considers native to a web app. and 2. Trying to >>>>>> provide a textual affordance where the visual affordance is only present >>>>>> on the users prompting. This means that there will be more everpresent >>>>>> textual affordances as there is no clear way to make the affordance only >>>>>> available upon the users request. >>>>>>> >>>>>>>> >>>>>>>> Alternatively, can we make the item a same page link (a link seems >>>>>>>> more intuitive to me than a button for some reason. >>>>>>> >>>>>>> I suppose this should be doable, although we try not to prescribe the >>>>>>> markup if possible. >>>>>> >>>>>> And now that I go back to look at the option I really feel more strongly >>>>>> for my first suggestion. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Everett Zufelt >>>>>>>> http://zufelt.ca >>>>>>>> >>>>>>>> Follow me on Twitter >>>>>>>> http://twitter.com/ezufelt >>>>>>>> >>>>>>>> View my LinkedIn Profile >>>>>>>> http://www.linkedin.com/in/ezufelt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2010-08-24, at 1:02 PM, Justin Obara wrote: >>>>>>>> >>>>>>>>> Hi Everett, >>>>>>>>> >>>>>>>>> Please see comments inline below. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Justin >>>>>>>>> >>>>>>>>> On 2010-08-24, at 11:30 AM, E.J. Zufelt wrote: >>>>>>>>> >>>>>>>>>> On 2010-08-24, at 10:11 AM, Justin Obara wrote: >>>>>>>>>> >>>>>>>>>>> In looking through some of our accessibility (a11y) issues, there >>>>>>>>>>> are several that I believe could use a little more thought and/or >>>>>>>>>>> discussion. >>>>>>>>>>> >>>>>>>>>>> FLUID-2964: >>>>>>>>>>> Research a11y best practices for re-orderer >>>>>>>>>>> http://issues.fluidproject.org/browse/FLUID-2964 >>>>>>>>>>> >>>>>>>>>>> This covers issues such as how to describe the layout of the >>>>>>>>>>> reorderable items. >>>>>>>>>>> >>>>>>>>>>> FLUID-2652: >>>>>>>>>>> JAWS announces that an inline edit area is a button >>>>>>>>>>> http://issues.fluidproject.org/browse/FLUID-2652 >>>>>>>>>>> >>>>>>>>>>> There are no specific aria roles that describe the functionality of >>>>>>>>>>> an inline editable field. The button role was originally chosen as >>>>>>>>>>> it seemed the most appropriate, but it still can be confusing to >>>>>>>>>>> screen reader users. >>>>>>>>>>> >>>>>>>>>> * What visual affordances are provided for inline edit fields 1) >>>>>>>>>> when inactive 2) when :hover 3) when :focus? This will help me to >>>>>>>>>> build a better mental model of how to translate the visual >>>>>>>>>> affordance to something textual. >>>>>>>>> >>>>>>>>> The visual affordances are of course, customizable, however I'll >>>>>>>>> detail the default style. When it is inactive, in view mode, it >>>>>>>>> appears like all of the other regular text on the page. On hover or >>>>>>>>> focus, it will have some focus styling such as a border. After >>>>>>>>> entering into edit mode (by clicking with the mouse of pressing the >>>>>>>>> space or enter keys) it will appear as a standard text field. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> FLUID-985: >>>>>>>>>>> Convey the deletable and completed states for file rows >>>>>>>>>>> http://issues.fluidproject.org/browse/FLUID-985 >>>>>>>>>>> >>>>>>>>>>> In the file queue for the uploader you are able to remove files >>>>>>>>>>> from the queue until they have been uploaded. The title of the row >>>>>>>>>>> was changed to read "File Uploaded" after it had been uploaded. >>>>>>>>>>> However, this does not seem to work across all screen reader / >>>>>>>>>>> browser configurations. Is this just a bug that needs to be >>>>>>>>>>> addressed, or is there a better approach? >>>>>>>>>>> >>>>>>>>>>> There are more details to talk about, the above commentary is just >>>>>>>>>>> a starter. Please let us know what your thoughts on the issues are >>>>>>>>>>> and how we can adequately address them. For more a11y issues in >>>>>>>>>>> Infusion you can take a look at the a11y filter we have in our jira >>>>>>>>>>> repository. >>>>>>>>>>> >>>>>>>>>> * Is there a good time for a group chat on these issues? >>>>>>>>> >>>>>>>>> I'm not sure exactly, I think if you reply on list we should be able >>>>>>>>> to work something out. Colin is away this week on vacation though, so >>>>>>>>> we may have to wait till after that. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> http://issues.fluidproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=10320 >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Justin >>>>>>>>>>> >>>>>>>>>>> _______________________________________________________ >>>>>>>>>>> fluid-work mailing list - [email protected] >>>>>>>>>>> To unsubscribe, change settings or access archives, >>>>>>>>>>> see http://fluidproject.org/mailman/listinfo/fluid-work >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
