Talk:Web and Software: July 11

Highly visible keyboard focus

• 9.2.2 Provide highly visible keyboard focus and text cursors
  • Software shall provide at least one mode where keyboard focus cursors and text cursors shall be visually locatable by people with unimpaired vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor.
  • EXAMPLE 1: The software provides an option of having a thick rectangle of contrasting color that moves to and outlines the control or field that has keyboard focus.
  • EXAMPLE 2: The software provides an option of having bright, yellow triangles extend from the top and bottom of the text cursor.
• If the control key, or similar could be configured to identify the focused widget in the same way as the pointer, would that also cover it?
  • It is marginal at best. Each time I hit the tab key I would have to hit the control key to figure out where it went. Maybe if it did it each time it moved too..? But then you have to change focus to find it. (sounds like the uncertainty principle).
• Would this work with the definition for legal blindness, e.g. visual acuity is 20/200 or less in the better eye with best correction, or their field of vision is 20 degrees or less in the better eye.
• Many desktops offer a "mouse trails" option, in which the mouse cursor briefly gets a tail or trail, where the last ~1/2 second of previous positions remain briefly on the screen to aid in their being located. It is easy to imagine something like Sean's control key suggestion - a mode in which the focused item is briefly more significantly visually indicated - aiding the user in locating it when the TAB key is pressed.
• The larger point is that there are a variety of innovative/novel ways in which one could aid users in visually locating the focused object on the screen. Larger "marching ants" or other static focus indication is only one of them. Whatever standard we put forth should be general enough to allow for new and novel approaches, so long as they meet the ultimate user need.
• That is why the provision is OUTCOME oriented rather than method oriented. It says what the outcome should be but makes not mention of how it should be met.
• Who is ultimately responsible for satisfying this provision? I fully recognize that if I invent my own widgets, it is entirely up to me. But if I code a simple web page today using simple components, the browser currently does *something* to indicate focus on every component. Because of that, can I safely make the assumption that the browser or OS is responsible for adhering to this provision, or am I forced to guarantee compliance myself?
• We should consider including "focus indication" in the "color, contrast, and other individual display attributes" language of 1194.21(g) / 3b.F. We should encourage (if not outright require) the platform to define the visual focus indication mechanism, and further allow users to set it platform-wide. Then your app, using standard user interface elements defined by the platform, should automatically comply with the platform settings, which in turn should meet the standard (or the platform itself would fail to be 508 compliant).
• On the web you can rely on the browser if you use HTML with no additional styling, if you do style your elements then that puts the onus on you to either test to ensure the default keyboard focus indication works well with your styling on the browsers you provide the style for; or you override the keyboard style yourself in a manner in keeping with the rest of your style.Similar arguments I think would apply to other app/platform combinations.
  • Not 100% convinced that the provision is completely outcome based as written. For example, moving the cursor is the reason this ability to locate is needed, thus if the enhanced location was a side effect of this movement it could not meet the wording.
  • Part of the requirement seems to be the ability to know the current context, so that I know what will happen if I hit the 'go' key (whatever that might be) - this is not necessarily provided by knowing the location of keyboard focus, it might for example be provided by a status caption if the control has some contextual modes, or as in the magnifier example, bye provided by an alternative rendering of the control in question.
• Is there some language that can include the relationship of the content in to the whole platform-platform scenarios? It seems like without that relationship noted the end-to endedness may not fully be achieved for what we are driving at. The deliverer of the item has responsibility for defining how accessibility is met for an item in what environments when constraints are known.
• When content is truly static content (and not executing code), the responsibility of a platform-derived focus indication doesn't lie with content. It lies with the software displaying that content. As far as the platform-on-platform issues, I think focus indication belongs with "color, contrast, and other individual display attributes" that must be conveyed from the underlying platform, through the platform-on-platform-application, to the app (e.g. from GNOME through the Java runtime on to the Java application). Our current draft language -still in discussion and not yet final - addresses this.
• Not sure how exactly to tie this in with "individual display attributes" in a way which leaves the implementation strategy open, but if we can do so, then it seems like the logical home. If you define HTML+CSS as 'truly static content' and if the CSS styles the content, then it would need to provide styles that either don't clash with the platform provided focus, or take ownership of styling the focus. OTOH if HTML+CSS counts as dynamic content.
• We have a potential limitation in the technology (HTML+CSS and the ability of the combination to respect color, contrast, focus styling, etc. of the underlying OS). Now, if content is perfectly viewable without CSS, and the user can turn that CSS off, and when off, the user agent styles content in a way that respects the color, contrast, focus styling, etc. of the underlying OS, I think we have a reasonable path to providing this functionality.

Discussion on content in general

• Comment that this is a very important (perhaps *most* important) provision to be added.
• Suggestion regarding where/how to insert it is, certainly choice A or B. It needs to be an overarching requirement, but leaning toward B because this is a Technical Requirement.

Remote system access

Allen proposed the following ideas and discussion items regarding accessibility requirements for remote access applications.

Background:

Currently often remote access from one system to another is implemented using text-based terminal emulation such as VT100, or 3270 protocols and clients, graphical user interfaces such as X-windows, and remote-desktop-protocol, and variations of each. For text-based remote access, scrolling text windows can be problematic for some assistive technologies to handle as much of that type of access was dropped when such technologies migrated from text-based OS(s) to graphical user interfaces. In graphical user interfaces such as X-windows, remote-desktop-protocol, etc, often assistive technologies must be operated on the server end, with sound being transmitted to the client. What is needed is that the client receives enough of the underlying accessibility information for each interface element from the remote end to pass to the assistive technology on the client end.

Proposed standard:

When software provides either server or client functionality for remote access to a specific graphical user interface, such software MUST pass interface element accessibility information from (proposed 21D) from the server to the client to then be passed to or inspected by assistive technologies.

Note:

I think we can exempt web browsers from this requirement as there are already other specific requirements for how content shall work in that context.

Summary of mailing list discussion

• Proposal only addresses the second of the 2 following ways to make a remote desktop session accessible through AT to a local workstation:

1. Run the AT remotely as well
   • GNOME challenge that is not yet solved: in X Windows, the standard way of doing a remote desktop is via technology called VNC, which redirects the entire desktop X video session into an X window (which could be a full-screen window) on a system across the network. Since X doesn't itself specify audio (that is done with different technology), VNC connections don't support audio.
2. Run the AT locally, and have it communicate accessibility information with the remote app.
   • this one may result in the preferred user experience (e.g. users may prefer one screen reader rather than two; though it might be rather weird to ask JAWS to make thoughtful sense of a remote UNIX/GNOME desktop, when JAWS doesn't know about some of the GNOME desktop user interface elements).

• Tom Brett proposal: "When software provides either server or client functionality for remote access to a specific graphical user interface, such software MUST make available interface element accessibility information from the server to the client to be inspected by assistive technologies."
• Allen's updated proposal: "When software provides either server or client functionality for remote access to a specific graphical user interface, such software MUST make available interface element accessibility information from the server to the client, which includes accessibility services minimum information, to be inspected by assistive technologies."
• Does this include or exclude web conferencing (like WebEx)
  • The intention is to provide a method for assistive technology to access an agency's servers and data. This would primarily be for federal employees who use assistive technology and who telecommute or are otherwise unable to get to their work area because of a disaster. Web conferencing would be covered by a different provision. Since the Government would need to procure the web conferencing service that service would need to meet all of the other software provisions.
  • Disagreement with above statement. The intention is to provide a method for remote desktop/GUI sessions to be accessible - or at least remote applications; not to provide a method for remote access to "data". I can mount a remote filesystem, and the connection from my desktop to that "data" is via file i/o commands. All GUI/command-line applications are running entirely locally. The "remote accessibility" challenge is for applications that are running remotely - and most especially for remote graphical applications, on a remote desktop.
  • Intent was not to include and exclude specific items exactly, but to try and describe what we needed for certain remote access situations for when one system is the remote terminal for operations on another. Proposal was restricted it to operation of a graphical user interface on purpose because it is aiming for products such as remote-desktop, Citrix, etc that allow real OS level access to another system and its applications. Web conferencing would not fit this definition as it is covered by web and other software provisions already, and it is a less holistic remote access than what I'm driving for.
    • Updated proposal to exclude Web conferencing: When software provides either server or client functionality for remote access to a specific graphical user interface, except for web-conferencing, such software MUST make available interface element accessibility information from the server to the client to be inspected by assistive technologies.
  • The original question was not asked with the intent of specifically excluding 'web conferencing'; it is probably wiser not to specifically exclude it. Typically, web conferencing software just sends pixels across the wire, not interface element definitions, so the receiving end cannot decipher it beyond just re-rendering those pixels. But if someone is clever enough to solve that, we certainly should not be discouraging them from doing so.