User Agent Capabilities

From Mobile Accessibility Task Force
Jump to: navigation, search

Thoughts from MATF


Different outcomes depending on platform, Browser versus App, specific app (YouTube, Ted), and automatically generated versus manually generated captions.

  • IOS even with Settings/general/accessibility/subtitles & captioning/closed captions plus SDH turned on, click on three dots in upper right and captions grayed out in Safari. No captions in Ted. YouTube only. manually generated.
  • Android Ted App, YouTube manually generated works, not browser

HTML 5 solves this: HTML5 video & track element seems to work

Viewpoint units

act differently on desktop versus mobile. On desktop viewpoint units override pinch to zoom, but they don't on IOS and Android They appear very small initially on mobile, however

Keyboard All Caps Consistency and Options

On iOS, all caps does not change the appearance of the keyboard. The keyboard always displays all caps. SOme low vision users find that the preferable solution. Other users (like cognitive) find it confusing that the appearance of the keys does not change with upper and lower case. Android keyboard appearance reflects the case.

UAAG Discussion: Importance of User Agent capabilities to mobile 12/11/14

Note: This is a discussion of the state of User agent capabilities on mobile devices – touch, keyboard etc. This is a preliminary step to including information on user agent capabilities in Note: WCAG 2.0 and Mobile.

APIs – some on platform and some on the browser. Speech control, braille display, switch control, even keyboard is some sort of API. And then there's the accessibility API that overlays all that sort of stuff.

User settings – browsers might have settings different from platform settings That may allow finer tuning. Sometimes they use different terminology, but they don't necessarily grab platform settings. You can set one text size on the platform and then at least my android has a whole different set of accessibility settings – scale by defaulting minimum font size, invert screen rendering, that may or may not be available in the platform but that are separate. I can turn JavaScript on and off, turn on and off plug-ins. Advanced settings for individual websites. Auto fit pages – there's other sorts of settings that are available not related to the platform.

There may be plug-ins that you can use that modify behavior further that are specific to the user agent and not related to anything else in the platform.

Tricky – there's no requirement outside of CVAA on the platform itself – just screen reader which have led to the platforms themselves being better, but there's no standards. They're just sort of winging it. I think user agent should focus on what it does – given the platform you have with the best thing that the user agent should have.

All the things we say in UAAG – just have to move this forward.

Where does WCAG leave off and UAAG – If someone has gone through the trouble of meeting WCAG, want to acknowledge that, for instance language requirements. How do you know if they actually did WCAG right – well it displayed in the browser the way you thought it should. If the author did the right thing and the browser did the right thing the user gets a consistent experience.

If UAAG has repair functionality as part of the success criteria you could get some false positives. Your user agent is repairing things that could be faulty vis-à-vis WCAG. there is only very limited repairs stuff now – hard to test. It says be careful when you Repair – don't stick the filename in as an alt text value. We worried about the false positives and took out a big chunk because of it.

User stylesheets – should be addressed somewhere. CSS is one of those repair type things that can help. But I wouldn't included in the platform facility of mobile because it isn't a browser and you have a choice of browsers on a mobile system.

The platform page – we assume it's the operating system but the browser is also a platform.



UAAG mobile examples