– DRAFT –
Defining views

JJ: today's session is about defining views

Slideset: https://janjaap.com/tpac2024/

JJ: the slides are on https://janjaap.com/tpac2024

[introductions]

JJ: we'll start with current definitions in the guidelines

JJ: a web page, in WCAG 2.2 is a “A non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent. Web page in WCAG 2.2 ”

JJ: in WCAG 3, it's “Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2, but are not restricted to content meeting that definition. For example, a view could be considered a “screen” in a mobile app or a layer of web content – such as a modal. ”

JJ: then in WCAG2ICT, there is also a definition that applies to non-web context

JJ: the equivalent unit of conformance for non web content is a single document, so set of web pages would be a set of documents, but then a piece of non-web software into pieces isn't possible, so 'web page'. becomes 'software program' and 'set of web paegs' becomes 'set of software programs'

JJ: in this session I want to see if we can get closer to carving up software into screens or views

JJ: that would allow us to speak of 'set of screens'

JJ: in WCAG2ICT, there are a number of notes under the 'set of software program' heading

JJ: first note says 'set of software programs' is rare

JJ: because there is many notes and exceptions, in my view we'd almost never speak of a set of software programs

JJ: in software like the office suite, that comprises of Word, Excel etc, would that be set software programs? in my opinion it would not

JJ: our group looked at how we would we apply those to mobile

JJ: in our group we wanted to think in terms of 'set of screens' for an app

JJ: there are different kinds of views in Android and iOS

JJ: screens can go onto or be popped off the stack

JJ: in a website there is usually a homepage, with sub pages and sub pages underneath, so there is hierarchy

JJ: on an app, there are activities

JJ: so my main question is: how should we define views? and define parts of the screen like we devide parts of web sites?

<Zakim> hdv, you wanted to ask about office suite

hdv: Just about the Office suite, that is not a set of programs?

JJ: As far as I understand because it is not able to switch between them such as opening an Excel file in Word

hdv: Other examples?

JJ: I have not seen a real world example of a set of software that would meet this

hdv: Do we know where this came from?

JJ: Not sure
… Some things are slightly different in software. It is odd to me that there is no real world example

chuck: I have limited knowledge of the institutional history of WCAG2ICT

chuck: I believe in the current group the definition was heavily influenced by what's in the original note

chuck: the charter didn't give us a lot of space to change a lot of the existing stuff in WCAG2ICT and focused mostly on embedding the new success criteria

JJ: on GitHub it seems people mostly agreed on wanting to change to set of views rather than sets of software, but it would be hard to define views in a way that works in non-web contexts

<Zakim> alastairc, you wanted to ask about using a concept similar to an starting point (UIcontroller, webpage etc). For example, a view is "a set of features that are all available from the same starting point, without transitioning to a completely new context."

alastairc: this is an important one to get a definition of

alastairc: as it is widely used

<kirkwood> +1 to alastair regarding importance / need

alastairc: inspired by the diagrams you showed, I wondered if we used something as a starting point, could we define a view something like 'set of views that start from the same starting point'

alastairc: what I've always found difficult with web page definition and related things, whenever you get modal dialogs or bottom sheets on mobile, you get things that appear over the top, but you're still in the same context

JJ: I think tree view would help to show hierarchy

JJ: on Android/iOS a popup still shows in the same window

JJ: and also traps focus

JJ: and similar to how desktop software would work when you show an alert of bottom sheet

JJ: when is something considered a view vs when is a substantial change? eg when you go to next view, that's quite clear but defining it is hard

<kirkwood> +1 to substantive change a design document incorporates it.

alastairc: a way to find out what's in scope and what's out when you're creating a definition, is to gather examples

alastairc: find the obvious examples of what's in and out of scope, and then find as many niche in between cases that you can

JJ: was thinking, if you would move between views you can usually use a back button to go back, that might be part of the definition we're looking for

<kirkwood> UX documentation often has language regarding this

kevin: I'm not sure if you're looking for a definition that is programmatical… from an assessment point of view you might not know what is underlying… maybe this highly depends on context?

JJ: agreed

JJ: maybe there is something there like a going back/forward mechanism

<Zakim> alastairc, you wanted to comment on process vs views

alastairc: in terms of forward and back… is one useful indicator… in WCAG 3, we've got to 4 levels: component, view, task flow / process and product

alastairc: they are used in scoping and conformance and so forth

alastairc: not sure how widely applicable forward/back is across different technologies, eg thinking epub and WebVR… it's an indicator but not the whole thing

kevin: re forward/back, is good as a baseline if we find and define the edge cases around that

<alastairc> What if you go to a new context but there isn't (intentionally) a back?

JJ: in my experience, auditing an app, I only have processes, almost no screens in an app or software are standalone

JJ: would be interesting to explore some edge cases

<kevin> hdv: Just thinking that when you follow WCAG-EM you gather pages for a sample

<kevin> ... If I think about gathering views, I wonder how much there is in the view

<kevin> ... Views in apps could be quite small steps

<kevin> +1 to the small steps

<kevin> ... I feel that there is something like how useful this is as a definition for an assessment

<kevin> hdv: If you were sampling apps would you be using this definition... eg, with WCAG EM

kevin: wa thinking the same for a lot of apps, a single question could be a view and you'd have many similar ones

chuck: re defining a view… does each view have its own title?

JJ: not always… in apps we'd talk about a screen which has one or more screens… the top bar would have a title and actions

JJ: and underneath there is a scrollable container

JJ: so usually on a screen you would have a title, but not always

kevin: we spoke a few months ago about updating WCAG-EM, would we look at using this new definition to inform an update of WCAG-EM?

JJ: maybe like WCAGICT-EM

<Zakim> alastairc, you wanted to comment on tab bars

alastairc: going back to that JJ mentioned most apps are like a back/forward process… a lot of apps have a tab view whicih is kind of like a starting point, like a tab bar at the bottom, each starts its own set of features/functionality, whicih would be the basis for review

<kirkwood> we used to call them simply layouts… later called them [UX) Layouts. this is based in print though

alastairc: I mentioned gathering examples… one place where I saw a good way of visualising it, designers create big flows in Figma, I couldn't supply one of my client's ones, but if we had a set of those, you could almost start drawing which chunks constitute a view

alastairc: that might help as an exercise

kirkwood: I think of what we always used to use… the old terminology, we're still using, layout as in print pages… when the layout changed and there was a significant change in the layout then that woulld be something to be approved by the design team

kirkwood: that might give us some structure

Francis_Storr: similar line to kirkwood… there is many things that can change on a page, so coming up with a definition of a view and then defining what other things are, eg states on a page… eg WCAG 3 talks about states and layers

Francis_Storr: or a different tab in a tab panel, are they different states in the view

Francis_Storr: views are important, but what do we call those other things?

JJ: feel the same logic would apply

Francis_Storr: eg if you restore state does that also update url fragment?

JJ: if I'd navigate between a tab I would represent it in the URL

<Francis_Storr> https://www.w3.org/TR/wcag-3.0/#dfn-views

alastairc: we're in that horrible position to define a line on a continuum, if you have a screen open and you have a dropdown, that's not a new view… but if you open a small popover to add an image in a document, that's prob not a new context, but a modal, is that a new view (seems like in WCAG 3 that would be a new view)

alastairc: there are also horrible sites that are a bit like a carousel but each arrow takes you to a new page… could be one page or multiple

<kirkwood> this is a very, very significant concept! from the COGA accessibility is the change in ‘view’ causing the loss of context and getting back to view and with it is ‘unfamiliar’ and thus losing orientation.

alastairc: we're trying to define a point on a continuum

JJ: existenceo of a back button would help

<Zakim> alastairc, you wanted to comment on the continuum

JJ: one issue on a modal you would be able to go back

<alastairc> Use of "view": Scoping the (or a) unit of conformance in WCAG 3

hdv: maybe what we need to define or leave undefined can be informed by where it is used, eg views might need to be used for WCAG-EM, other terms may not be used testing any criteria so we cna leave them undefined

Rachael: what about content that is repetitive but not on the same page eg in tabs?

kirkwood: this is just an important concept from the COGA perspective

kirkwood: the aspect of changing view and getting lost in a view, not understanding how to go back… it's something we're trying to get our arms around with defining a lot of things that you're talking about too

kirkwood: maybe some of these things can be collaborated on with the COGA TF as some of these things can really break a11y for visual orientation and memory purposes

JJ: would be great to collaborate and see previous work

<Zakim> alastairc, you wanted to answer hdv's question

alastairc: re Hidde's question: this is a unit of conformance for WCAG 3

alastairc: trying to be more accomodating to modern web and non-web context

alastairc: thinking about next steps… if we were doing a subgroup on a guideline we'd start a google doc and capturing screenshots and different examples

alastairc: and use that to poke on proposed definition

alastairc: is it worth doing that?

JJ: good idea

JJ: can get examples from apps, other non ICT and also web

chuck: +1

hdv: In the WCAG3 space, would that delay it going into WCAG-EM

JJ: we can probably take it back to WCAG2ICT? maybe

chuck: chatted to Kevin re this, there are some things needing to be discussed, also non-technical things, we need to have some conversations first

JJ: so would wonder if WCAG3 subgroup is the right forum

alastairc: WCAG3 is very active, but WCAG2ICT is in final stages of their publication.

JJ: but they are still going to work on AAA

JJ: would be great if updating 'sets of views' could be part of their updates potentially

alastairc: all of these TFs run under the AG banner anyway

JJ: to summarise, we can explore back/forward, view changes, and maybe look at setting up a subgroup to try and research this definition

JJ: to make a document to showcase these views across a wide range of things

hdv: I'd be happy to help with that

<Rachael> Thank you for a good conversation.