Meeting minutes
2.5.1 Pointer Gestures
Jason: If we have a good one it may become relevant
Matt: I was thinking about a scenario where you have to make particular movements to select text, it may be keyboard equivalents for these though
… I suspect that is unlikely, but I have little experiences using the modern GUI ones
… You have to make sure you have provided an alternative
Jason: It would be possible, I just could not think of a good case
… We need to take a careful stance at this
Matt: There is nothing in the platform that stops it from being a potential failure
Jason: And an emulator could fail as well
Matt: Yes. For example dragging files to different directories
Jason: I think it is, I just could not come up with a good example
Jason: We could say to both columns and put a note that we are not aware of examples but still there is the possibility of failing it
Matt: I was thinking about the DOS shell, the modern one that renders in a web page
Jason: I would be comfortable with yes to the two, as said above
Pointer Cancellation
Matt: Same as last one
Jason: Same as above
2.5.7 Dragging Movements
MAt: IF we are considering text editors that take up terminal functionalities it sounds to me like the same thing, it should fail
Jason: a note that we don't have any good cases. I wouldn't think that is strong enough
On Focus and On Input
Matt: I think we did admit the possibility that we can talk about things getting focus because there is an onscreen indication
Jason: We said that is not the system focus, and that may prevent the guidelines from applying
Matt: Definitions of "change of context" are quite broad. I think it is a lot less likely in this types of applications.
… I'd think this is completely relevant for a terminal emulator where there might be a specific setting
Jason: It is still debatable if some highlighting within a terminal application constitutes "focus" per se. IF we consider it relevant, we should say yes
… I don't have a strong preference
MJ: Is it that it is not programmatic?
Jason: Yes.
Matt: The focus might be on the terminal "canvas". The most accessible terminal apps just push out lines and the screen reader reads the lines
Jason: Focus may be where the system cursor is. That may unrelated to something that is highlighted
Matt: You can move different cursors to different places.
… Some apps put a chevron next to where they expect input, and then input cursor moves there without the user noticing it
… In addition, when you move the mouse you are also moving some of the interactive prompts. Not sure if the screen reader cursor would be moved as well
MJ: Sounds like yes for terminal emulator, for output I am not sure
Matt: I have a feeling that we accepted focus visible as relevant, thus we should accept this two. I will make a note to check if the answer for 2.5.2 can be the same as well for 2.4.7.
… IF it is the same, we should say yes
MJ: I'll keep this marked with different answers until we are clear on 2.4.7
Consistent NAvigation
Matt: This is one where the stricter definition can constrain it
Jason: Yes, difficult to adapt
MJ: With the interpretationof WCAG2ICT a terminal application could be considered applicable
Jason: You could have a text-based web browser inside a terminal application. If there are issues there, it goes to the accessibility of the content
Matt: We are talking about a "set of programs" according to WCAG2ICT definition
MJ: I would set even though we have sets of software programs it still won't be applicable
Matt: I think we are fine on this
… It would be nice to have just what Jason described
Jason: You could have a text-based browser but still it would not be a "set of web pages"
Consistend Help
Jason: Does it have to do with "sets of web pages"?
MJ: Yes.
Jason: Same problem as above
Matt: It depends how we translate the term
… As it is been translated, I don't think we could say this is relevant
Jason: I think it is effectively the same as the previous issue
MJ: This seems the same. It is a "no".
Redundant Entry
Jason: I think you can do it on the applications. I can't think of a good case to do it on the interface of an emulator
… It is not similar to how electronic commerce applications are
… I'd be comfortable either way
Matt: I thought that we should be using the same approach that we used earlier, but here we are talking about terminal emulator
… The reason we considered pointer gesturesin the apps is because they can handle them however they want. I can't think of a terminal emulator that would have a step by step thing for this
Jason: That is what I am concerned about
… It is extremely unlikely to happen
Matt: We are here to provide some guidance
Jason: I would say extremely unlikely
MJ: We have language for that already that we could use
Status Messages
Jason: I think we cannot weave our way through this language.
Matt: This came up before, we should approach it however we approached those
Jason: I think we said we cannot ignore that. I'd be incluned to say it can't apply, but put a note about the fact that you should consider cases where it technically does not apply, but the same issues can arise in an application
… For example for makrup, I am not clear if the problem could occur in a terminal application, it could potentially happen in a terminal emulator
Matt: There could be OS notifications
MJ: How do you find these?
Matt: It either beeps or puts a dot in the relevant tab
… You could use notifications, sounds etc
… We had similar issues with Input Purpose and Info and Relationships. I'd like to make them work, but we need to be consistent
Jason: There would be an advisory suggestion that people should consider it anyway, but can't apply to the current success criteria
MJ: We can say something like "It is a best practice for users to know the status by using certain methods"
Matt: The shell has a prompt, and the prompt is read aloud after each command
… They would announce intermediate updates
Jason: Since there is not accessibility API you still cannot meet the programmatically determinable
Matt: If it is possible to certain screen readers to tell which parts of the screen are active ...
Jason: But that wouldn't be programmatically determinable
Matt: Do not modern screen readers do that?
Jason: No, I think they default to reading the output
Matt: I think it is inapplicable because of the "markup" and the "programmatically determinable" but add a note to please include this
… For example, could you write a screen reader script for a terminal application?
Jason: Not sure, for an emulator you could though
Mat: I'd be interesting for us to see if this technique can or cannot be used
Jason: That is right
MJ: If there is additional guidance that should be written as to what terminal emulators should do, that would be outside of scope for WCAG2ICT
Jason: I think we can take care of that
Matt: It is unreasonable for the screen reader to know what program is run, but the terminal emulator knows that. Based on tihs info they could decide to ignore parts of the screen
Jason: If it appears in the window title you could write a script, there are options, we may need to discuss them at some time
MJ: This is the end of A and AA Sucess Criteria
Jason: In a number of instances so far we've had to make decisions on interpreting questions and they are related to what WCAG2ICT did. We may need to wait for the AAA ones until this exercise is done
MJ: Yes, it is all on the spreadsheet and will be referenced from the wiki
… I think next steps for us is to document the problematic aspects
Jason: Janina was doing it. I'd like to wait for her to be in the meeting for us to comment on that