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
