Success Criterion 1.3.4: Orientation (Level AA) about wcag2ict

[pday1]

Devices that are fixed in place - it doesn't matter if there is a sensor or not - it's still not going to be feasible to change the orientation.
The example that was mentioned on a previous call was a large physical product such as an ATM or kiosk - where the touchscreen is part of a larger physical product and cannot easily be changed in orientation.

[maryjom]

@samogami In the meeting on 17 November we had tweaked the note to be:

Content that is only used on hardware that is fixed in place OR that has no sensor to detect or change the orientation is covered under the essential exception and not required to provide support for orientation changes.

See the minutes of the discussion for Survey: Draft of SC 1.3.4 Orientation.

[pday1]

I wonder if the note should be broadened slightly:

Note: Devices that are fixed in place OR have no sensor to detect or ability to change the orientation would be covered under the essential exception and not require software support for orientation changes.

[ThorstenKatzmann]

would it promote accessibility? as a manufacturer, you could always omit the sensor or prescribe a fixed position

@pday1 can you give an example? I think it would help.

[mraccess77]

FWIW I have seen kiosks where the screen takes up y height but when you press the accessiblity button the screen takes up the bottom half of the screen only so the touch controls are in reach for people who use wheelchairs or cannot reach them for other reasons.

[ThorstenKatzmann]

thanks @pday1, thinking about the note and the OR: could the sentence be read this way "Devices that have no sensor to detect would be covered under the essential exception ..." that would exclude all devices without sensor, even if they have the ability for changing the orientation.

[samogami]

I would recommend keeping the note the way @pday1 originally suggested.

Devices that are fixed in place or have no sensor to detect or ability to change the orientation would be covered under the essential exception and not require software support for orientation changes.

The rationale is that some devices with sensors can be "fixed in place" or the other way around, and the success criteria are not applicable.

Examples:
An ATM is a "fixed in place" ICT and has an anti-theft sensor to prevent/alert when the device is being oriented on its side.

A desktop ink printer that is not "fixed in place" but has a sensor to ensure the printer is on a level surface for printing.

[maryjom]

@mraccess77 Regarding your comment on this issue quoted below, I'm not sure I understand your comment, quoted below.

FWIW I have seen kiosks where the screen takes up y height but when you press the accessiblity button the screen takes up the bottom half of the screen only so the touch controls are in reach for people who use wheelchairs or cannot reach them for other reasons.

The Orientation requirement isn't requiring the ability to move screen content up/down, but about not restricting movement between horizontal and vertical orientations (per the understanding document). There are cases where hardware is large and bulky, or installed in a fixed place where the restriction is physical - you can't reorient the screen, so the notes indicate that in such cases the orientation would be essential. Requiring software capabilities to reorient the content between horizontal and vertical would be unnecessary work.

This doesn't preclude software from implementing the ability to adjust content up or down based on height needs, but it seems that would be a new requirement - which is out of scope for our task force. I don't think that implementing content to adjust up/down would satisfy this criterion, as written, either.

[mraccess77]

The point that I was attempting to make is that in my opinion orientation is a term that is not restricted to landscape and portrait. So if the user could change the display then the content should not be restricted. I wasn't thinking of display as being limited to a physical thing - display changes that impact orientation could be software based.

I do agree that if the display - whatever that is - cannot have orientation changed then the requirement would automatically be met and there would not be a need to spend time testing that.

[maryjom]

@mraccess77 Thanks for clarifying. Makes me think that there may be a need for another note. I'll bring it to the task force.

[maryjom]

AG WG has a survey open until 16 March with AG WG survey results discussion on 21 March (after CSUN conference).

[maryjom]

On 21 March, the AG WG approved SC 1.3.4, with changes that have been merged.