Meeting minutes
<Jemma> https://
APG redesign project update
<Jemma> APG redesign repo was set up and add various report and design mock up
<Jemma> we can talk about the update at next meeting
<Jemma> https://
<Jemma> issac: wireframes does not include new features yet. Info architecture will be the first step
Jump Tp
<Jemma> https://
MK: The main issue is that it really works well for everyone by VO
<Jemma> Matt's concern - https://
MK: It kind of works with Chrome if you use pass through key
MK: If we are going to model it, we don't want to leave some people out
MK: Suggest using JS for creating a hot key
MK: There maybe conflicts with examples, or other artifacts
SH: We had a discussion, that accesskeys aren't great, users are not familiar with accesskeys, scripting makes it more consistent
Siri: If you use a modifier...
MK: We will definitely use a modifier
MK: We could use ALT+zero, not super intuitive, but ALT is used for accesskeys in Chrome
JG: Accesskey information is announced by screen readers
MK: Does the screen reader add it to the label
SH: It is not to do with authoring
Siri: It automatically adds the shortcut key
<siri> +1 sarah
MK: I am not sure who is doing it, we have aria-hotkey, but that doesn't work with VO either
SH: We could add shortkey to the button label
JG: We already have the tooltip and we could add back in the aria-describedby
MK: It could get rid of the tooltip if it was in the menu button label
MK: We have some examples that were not looking at modifier keys
MK: We could make a terst for that
MK: It is on a list that we could test, that do not have a corresponding item in the keyboard table
MK: We will script ALT+0 and include the Keyboard assignment in the name of the button
MK: It is a button
JK: Status of review of the example, done with my review, we need other reviews
JK: When I use Jump To click it does not focus the the target
MK: You want a keyboard focus ring on the target item
JK: When you use the keyboard you get a focus ring and with the mouse no focus ring
MK: You are talking about after you click
MK: You can't tell you navigate to the item
Siri: If you have a skip link it doesn't show focus
JK: I don't understand
Siri: When the focus is shown on the main element, it is not interactive
JK: The sighted user gets different experience using the mouse and the keyboard
MK: I am curious about this the visual experience
JK: The keyboard way it works as I expected
JG: Functionally it still works the same with the mouse and the keyboard, the only difference us the focus highlight
JG: I will look at why the focus ring does not show with the mouse
HTML Range Slider Example
https://
<Jemma> HTML Temperature Slider PR #1757
JG: We need reviewers
MK: We need to have reviewers assigned
JG: Example is ready for review
… assigning reviewers ..
JG: The JS is short, but the CSS is more complicated
MK: In this case, I am still kind of torn about keyboard documentation
<Jemma> https://
JG: I put keyboard support under accessibility features
MK: I wonder to stay with our template, and go ahead and document it, but say the keyboard support is provided by the browser
<Jemma> Keyboard support for the temperature control is provided by the native keyboard support for the input[type="range"] element (i.e. Up/Down Arrow, Page Up/Down, Home and End keys).
MK: Is page up and page down different on browsers?
JG: probably
MK: I am curious what the difference is between chrome and safari browsers
MK: I think we should document it
MK: From a functional review to do? We can't change the function of the browser, so we are testing is the changing the valuetext
JG: SHould I put the keyboard table back in?
MK: Yes, but I will make some edits
<Jemma> https://
<Jemma> Functional review
<Jemma> Exercise the example with keyboard, mouse, and touch in Chrome, Firefox, and Safari to ensure:
<Jemma> Keyboard behaviors match the pattern documentation.
<Jemma> Mouse and touch behaviors match expected norms.
MK: We don't have any keyboard events
JG: The browser change evant it is not triggered by key down events
<siri> diff between browser chg event and keyboard chg event?
MK: So when you press the arrows the value doesn't change?
SH: The input event may fire on keyboard events
SH: Look on the input event
MK: Who's spec is that?
<Jemma> this is the code sarah mentioned,
<Jemma> this.rangeNode.addEventListener('keydown', this.onRangeChange.bind(this));
SH: Good question, I am not sure where it is
<Jemma> this.rangeNode.addEventListener('change', this.onRangeChange.bind(this));
SH: There is change events differ on input controls, text input they are pretty much the same, when they are different change occurs less than input event
MK: JG please try input event
SH: I will not say input is more consistent between browser
MK: We need to test on all three platform
BG: It might work on iOS
BG: Is it in the APG right now?
https://
BG: I need to build one soon
JG: I need to make changes to it
MK: There is a fair amount of functional review, and I will test with iOS
JG: I will try to test on all the platforms, just curious
MK: What about high contrast?
JG: We have a focus ring around the thumb
SH: You have to guess by the position
MK: So it makes sense in making custom sliders, you can add more features
SH: The track is tiny and hard to use the mouse with
SH: If you use the pseudo properties, you cannot style the background color of the rail
<Jemma> https://
MK: It is easy to add a range input, but difficult to style
Unicode Symbols in CSS Generated Content
<Jemma> https://
JK: According to WCAG it is not recommended to use unicode
JK: Practical issue is up and down arrow, for indicating collapsed and expanded
MK: Is it something we want to show people how to make accessible
JK: I don't think we should unicode in HTML or CSS
MK: It is strictly a visual thing
<Jemma> Description
<Jemma> The objective of this technique is to show how to provide a visible, text alternative for an Unicode character that conveys information.
<Jemma> Some versions of assistive technologies will announce CSS generated content, as well as specific Unicode characters. However, because the announcement may be inaccurate aria-hidden="true" is used so it will be ignored by assistive technologies. An on-screen text alternative is added.
MK: CM was leaning toward this
MK: Any other comments on use of unicode?
Siri: You have to use aria-hidden if it is not useful
MK: Are we using aria-hidden, we are using css properties to make arrows
<Jemma> this is the code we are using
<Jemma> .disclosure-nav button::after {
<Jemma> content: "";
<Jemma> border-bottom: 1px solid #000;
<Jemma> border-right: 1px solid #000;
<Jemma> height: 0.5em;
<Jemma> margin-left: 0.75em;
<Jemma> width: 0.5em;
<Jemma> transform: rotate(45deg);
JG: We are currently using aria-hidden or using borders to generate arrows
MK: BG what is your thoughts on using unicode characters
BG: I don't recommend the use of unicode characters
MK: We don't want ATs to pick them up
MK: These are arrows to indicate state in menus
BG: We will override using accname techniques
BG: We also use aria-hidden
MK: You actually use unicode characters
BG: It is useful in some cases, but you need to prevent exposure
SH: Not a big fan of using aria-label to override, translation issues, use aria-hidden
SH: It looks like we are not using the aria-hidden