Accessibility Guidelines Working Group Teleconference -- 09 Jan 2018

<AWK> +AWK

<Joshue108> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 09 January 2018

<Joshue108> ok

<laura> Scribe: Laura

awk: meeting tommorow. will send out info

Survey: https://www.w3.org/2002/09/wbs/35422/resolvingissues3/results

Issue 408

David: misunderstood the word essential
... make it clear that it is about the contrast.
... I think we have to add that "essential" in this case doesn't mean the use of a graphic is essential, but the use of non-conforming contrast ratios in the graphic is essential ...
... want to clarify whether we think providing a data table fallback would be a pass of this SC.

AWK: Michael Gower to append the definition
... Katie agrees
... Michael Elledge accept the response as proposed with David and Michael's additions.

Bruce: accept the response as proposed, but I do not think we have really addressed Kerstin’s concern that we have made “essential” more subjective.

gowerm: think she misunderstood the language.
... could redraft what I had before

<Mike_Elledge> laura, gowerm not Mike E

awk: we could clarify in understanding doc.

<AWK> https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#408

david: language is okay. clarify in understanding doc

awk: updated the response.
... mark as implementation follow up

jason: looks good to me.

RESOLUTION: Accepted as amended

Issue 520

DM: think we should add that the SC that he is asking for did not meet the minimum requirements for an sc with a link to the acceptance criteria
... strong comment.

awk: where could we add that?

dm: anywhere..

awk: could add a link.

david: we have clear requirements that we have to meet.

<Greg> They deserve responses explaining why each of their proposals were rejected, rather than pointing to a list of potential reasons. The latter comes off as arrogant and dismissive.

greg: commentator should have a more customized response.

awk: doesn’t the text do that?

<Zakim> Greg, you wanted to say they deserve responses explaining why each of their proposals were rejected, rather than pointing to a list of potential reasons. The latter comes off as

greg: we should let them know that.

<jamesn> ¨In the following, we reiterate our main proposals that we had submitted to you before:

<jamesn> ¨

james: should look back at the history.

greg: should be more precise in dates.

MC: move paragraph starting "Regarding the inclusion of requirements..."

james: maybe timeline is not an issue.

<jamesn> https://github.com/w3c/wcag21/issues/515

MC: remember another comment.

<Greg> I think that if we're saying their SC don't meet requirements we should explain in what way, and if we say they were too late we should specify when our records indicate they were submitted compared with the deadline. They may well come back with records of when they were submitted earlier, from them or an affiliate.

james: 515 is another comment from this org.

awk: I revised the reply in the wiki.
... what do people think?

MC: think it will be read as dismissive.

david: I could work on it. ready by the end of the meeting.

RESOLUTION: Leave open.

Issue 605

awk: general sense too narrow.

<AWK> https://www.w3.org/2002/09/wbs/35422/resolvingissues3/results#xq2

awk: David had a long response in the survey

david: would drop this example "For example, labels are not required, even on inputs (3.3.2: "or Instructions"), BUT, where labels exist, they need to be properly marked up (1.3.1) and descriptive (2.4.6)."
... I would not offer to remove markup at this point.
... not enough research or evidence
... glad to have a propose a technique
... There is danger that this would be poorly implemented and would degrade the experience for a screen reader user
... Perhaps in future iterations of the WCAG we can find standardized and testable ways ways of notifying users of content that updates frequently without this risk of interfering with their experience.

jason: ... Removing the "markup languages" restriction should be considered in order to ensure applicability of WCAG 2.1 to content/applications not implemented in markup languages
... concerned about restriction.
... implications for the Accessibility Object Model
... although there would be an underlying HTML document, the content may be implemented in, for example, a canvas element and there is no markup which corresponds to the UI controls that generate the status message
... think this SC would be better without the "markup languages" restriction.

awk: Katie agrees with David and Jason
... Mike Elledge unsure about keeping or removing the reference to markup.

MC: "With sufficient evidence, we can propose the removal of the "markup" restriction." is not an option now due to timeline.

ME: may be restricting things repoire. let people come up with techiques.

mg: would be one technique: ARIA

jason: disagree with restriction.
... no known technologies that it shouldn't apply to.

awk: meet though exclusion. technology independent way.

steve: what about future technologies?

<alastairc> There can be the case where markup languages generally support some things where others don't. E.g. over-riding styles.

mc: doesn’t break backwards compat to remove a restriction in a future version.

steve: most PDFs are static…like web pages.

josh: we want to restict to markup?
... addressing a real need today and future proofing are both important.

awk: we can always broaden an SC in the future.

jason: broadening in the future has becomes an issue with backwards compat.

<JF> +1 to that Mike

<Greg> ...refer to a separate document that can be updated separately.

mike G: we are entering into another question.

awk: not an insurmountable hurdle.
... clean change.
... what do people think?

<jasonjgw> -1

<Alex_> +1

<Mike_Elledge_> -1

<AWK> +1

<david-macdonald> + 1 to keep it

<JF> +1

<Makoto> +1

<JakeAbma> +1

awk: plus 1 to keep in markup -1 to remove it.

<Detlev> Don't know

<bruce_bailey> +1 to keep mark up in

<Mike_Pluke> +1

<Glenda> +1

<Joshue108> +1 but verging on 0

<Greg> 0 I'd like to see the restriction removed eventually but it need not be done now.

<Brooks> +1

awk: feels like we age getting clarity

mg: friendly changes. I can integrate.

<Zakim> Greg, you wanted to say whether we have the option to structure the scoping to formats in which an accepted method exists (e.g. something like "Status messages can be

greg l:

<Greg> My suggestion would be equivalent to 1.4.5's clause "If the technologies being used can achieve the visual presentation ..."

scribe: alternative way to 1.4.5
... could use “if the technologies can…”
... could have a external doc with exceptions.

awk: that would be a major change.
... concerned about takeing that route at this point. Entering CR.

<chriscm> But it is obviously pointed at one technology...

ME: is limiting to markup lanuages tech agnostic?

awk: no

<Greg> I think in the future we should consider using more widely the approach used in 1.4.5 is better than being *somewhat* technology-specific by saying it applies only to markup languages. But as I said above I think time it too short to do it now.

<alastairc> the technology agnostic aspect is about including multiple technologies, rather than making things specific to one technology. "Markup" includes HTML, SVG, ePub (probably more).

RESOLUTION: Accepted as amended

Issue 656

RESOLUTION: Accepted as proposed

https://www.w3.org/WAI/GL/wiki/index.php?title=Draft_Responses_to_Dec_WD_Issues&oldid=9012#644

AC: commenter has made several comments on PDFs
... scoping to markup languages solves the issue.

Jason: wondering if I made a comment on it.

awk: already did that one.

https://www.w3.org/2002/09/wbs/35422/resolving_issues_2/results#xq13

jason: Is the argument in the response that PDF cannot meet the "allows changing of text style properties" condition or is it proposed instead that there should be an "in content implemented using markup languages" condition added to the SC?

AC: didn’t understand the question

<jallan> current language: f the technologies being used allow the user agent to set text style properties, then no loss of content or functionality occurs by setting all of the following and by changing no other style property:

jason: have to revisit the "technologies allow setting of text style properites" idea

<jallan> +1 to Jason

jason: language already excludes text syle properties.

AC: VIP reader completely reenders the content.

awk: could modify understanding. or update SC.

<jallan> fix in understanding

<Detlev> scribe switch?

<Detlev> I can do it

<Detlev> Scribe: Detlev

<laura> thanks, detlev.

Changes are in te wiki

<jallan> agree with Andrew. It is the User Agent that is limiting the users ability to change settings

Alastair: advantagous to reference mark-up languages

<jasonjgw> -1q+

AWK: SCs cannot speak about "the user doing things.." - to be avoided

Jason: perhaps rely on accessibiltiy support concept
... if there is no support for setting styles in PDF than it would not apply

AWK: different from the use of accessibiltiy support in other contexts
... should not be in the SC language, it is an overriding concet

<alastairc> Happy with the markup approach? "In content implemented using markup languages, then no loss of content or functionality occurs by setting all of the following style properties, while changing no other style property:"

AWK: Straw poll suggestion

steverep: language was carefully crafted - are we saying it cannot be satisfied in PDF, or cannot be tested?

Laura: we want to say it is not doable

<AWK> +1 to keep current language (if technologies being used) and -1 to change to "in technologies implemented using markup"

<alastairc> -1

-1

<AWK> -1

<marcjohlic> -1

<JakeAbma> -1

<JF> -1

<Alex_> 0

<jallan> +1

<Mike_Pluke> -1

<laura> -1

<bruce_bailey> -1

<Greg> +1

JF: concerned that it is not (about ) technologie but content

<bruce_bailey> agree w/ jf

<AWK> "In content implemented using markup languages, "

JF: testing focuses on content, not technologies - so it should be content implemented using markup languages

<alastairc> The proposed response & new text did say content.

AWK: JF you are right, straw poll formulation was wrong

<jallan> so, if I have an html page, and using a mobile browser that does not allow changing any of the parameters. does the content fail. How is this different from PDF.

JF: even word processing has interchangability via markup behinf the scenes - are we saying it would be applicable even to word porecesseing?

Alastair: could be easy to meet - but PDF is more a db of objects
... text properies can be changed in Word
... PDF not (as easily) editable

JF: Google docs can be made non-editable

Alex: once you reformulate you are an author

Laura: we are talking about user style sheets

JS: Have tension between technology-agnostic and casting the net too wide, catch techs that are out of scope

Jason: techs (mark-up languages) if UA allows in principle to set style properties the SC is applicable

<Zakim> Greg, you wanted to say What about an approach where we essentially define "if the technology being used allows" to mean both in theory and in practice, that is at least one (or

<alastairc> So with current (tech) language, we catch: anything which allows user-agent to over-ride certain properties, which is HTML, epub, and anything with author-access.

Jason: other Markup languages (XML types) may comin in scope of web content

<alastairc> With markup languages: HTML, ePub, SVG, anything else?

<Greg> What about an approach where we essentially define "if the technology being used allows" to mean both in theory and in practice, that is at least one (or perhaps 2) user agents support this feature of the technology?

Greg: agrees with commenter - if technology allows.. is problematic - better phrasing possible

<jallan> something like -- If the technologies being used allow the user agent to set text style properties, then no loss of content or functionality occurs by setting those of the following supported by the user agent and by changing no other style property:

<alastairc> I think the bottom line is: We want to catch HTML & epub, and don't want to catch PDF.

The languag would suggest that the SC fails if one of the four cannot be modified

<alastairc> So either use 'markup langauges', or say that PDF doesn't allow it

AWK: we may want to catch PDF but are currently unable to

<Greg> I’ve in the past had the same concern as the commenter about the difference between “if … to set text style properties … all of the following”. I agree it could be read as saying that if the technology allows overriding just one text attribute, everything authored in that format fails.

Jim: How is this different from a mobile browser that cannot set styles - PDF might allow it

<Joshue108> +1 to Jim

<alastairc> you can test the (HTML) content regardless of whether mobile user-agents support it.

AWK: easier said than done - comments from outside the group have pointed out that there are limitations in major formats they use

<david-macdonald> I just completed an amendment to issue 520 https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#520

Alex: In the WCAG context UA really means the browser, and those style changes are realistic and narrow - the EN standards look beyond that at documents with other UA like MS Word or other suites, which are not just UA but authoring tools
... so changing styles is part of authoring not setting style properties

<alastairc> NB: I've found quite a few low-vision / blind folks prefer word to PDF as it is then editable and adaptable.

<Zakim> gowerm, you wanted to say I think that we can clarify what technologies cannot currently comply in the Understanding doc

Alex: context will recur since these areas get closer

goverm: would not MS Word meet this?

<Joshue108> -q

<Greg> In general I agree with Jim that some file formats should not be considered fully accessible, and authors should avoid using them on the web unless they also provide the same content in a more accessible format. But I don't know if we can get away with having all PDFs fail at both A and AA at this time.

Alex: in principle yes but in some context like Powerpoint content would spill over, would become invisible - less of a problem in Word

<alastairc> +1 Greg, I'd be happy to make it a requirement, but if it is necessray that PDFs can pass, then I'd rather it be in for markup etc. than out altogether.

<JF> https://en.wikipedia.org/wiki/Comparison_of_e-book_formats

JF: concerns that mark-up techs may be too broad - eBook formats use all types of different file formats using mark-up languages that may not allow doing that

Alex: what to be done?

JF: its dependent on UAs, file formats -we need to find a sweet spot between "just HTML" and "any markup language out there"
... EN activites take a broader approach to digital content

AWK: do we have a response here?
... current language may be incorrect, mark-up may be too broad - any alternative suggestions?

goverm: proposes "in mark-up languages where the technology allows.."

<jallan> something like -- In content implemented using markup languages and the user agent is able to set text style properties, then no loss of content or functionality occurs by setting those of the following supported by the user agent and by changing no other style property:

<gowerm> In markup languages where the technologies...

goverm: so you would have both restrictions in the SC text

<Greg> I did suggest an alternate language/approach, defining the phrase "If the technology being used allows".

<jasonjgw> "For content implemented using markup languages where the technologies being used..."

(Detlev) sounds combersome but if it hits the nail..

<jallan> something like -- For content implemented using markup languages where the technologies being used is able to set text style properties, then no loss of content or functionality occurs by setting those of the following supported by the user agent and by changing no other style property:

<AWK> For content implemented using markup languages support the following text style properties, then no loss ...

Josh: just saying that David's response is ready as well

JF: long, but seems to cover it

<jallan> something like -- For content implemented using markup languages where the technologies being used is able to set text style properties, then no loss of content or functionality occurs by setting those of the following that are supported and by changing no other style property:

AWK: reading an alternative with a 'that' (not a which)

Alex: what is the technology? Would it be e.g. ePub or the underlying markup language?
... what is setting the text stype property?

AWK: focus on whether these properties exiast in these formats

<Zakim> steverep_, you wanted to say that the intersection of the 2 is simply any markup language that has those properties

steverep: goes back to a level of accessibility support - just test by changing your styles (as uthor) not needing more fancy testing

<jallan> +1

Jason: in the ePub cas we are talking about HTML and CSS, so that would pass

OOML would also pass

Jason: would fail for PDF because of mark-up languages restriction

<AWK> "For content implemented using markup languages that support the following text style properties, then no loss of content or functionality occurs by setting all of the following and by changing no other style property"

<AWK> "In content implemented using markup languages, then no loss of content or functionality occurs by setting all of the following style properties that are supported, while changing no other style property:"

Alex: how would we apply this to a Google doc or Word doc in the web use scenario?

Jason: if you use the HTML rendering of the underlying word format it would apply

Alex: trying to understand how it would be made to apply
... what technology are we talking about? The underlying tech (Word etc) or the browser and its rendering?

<AWK> echnology (Web content) mechanism for encoding instructions to be rendered, played or executed by user agents

Jason: the browser

correction: not the browser

<JF> +1 to Alex and Jason

Alex: how would the logic flow?

steverep: unless there is something that uses a plugin it comes through as HTML

steverep: properities of things like google docs are expected to be static and would not be affected by user style sheet changes

sonds great

<laura> +1

<steverep_> As long as we capture HTML/CSS, the bulk of user need is satisfied

<marcjohlic> +1

<bruce_bailey> +1

<JF> +1

<Joshue108> +1

<Mike_Elledge_> +1

<Glenda> +1

<gowerm> +1

<Makoto> +1

<Mike_Pluke> +1

<AWK> "Except when a fixed size content layout area is essential to the information being conveyed."

<alastairc> +1, just about following on my phone

<Greg> 0 as I still prefer my suggested approach.

AWK: one thing not covered is the request for an exception (for areas in Powerpoint DTP with fixed layouts etc.

<gowerm> I'd need to think about it more

AWK: any objection to adding this as exception?

<alastairc> Why needed, newspapers should be except?

<jasonjgw> Not objecting but noting that "setting" was removed, which would be clearer.

AWK: any objection to suggested wording AND exception?

<alastairc> Perhaps for authoring views, not layout types

<gowerm> "fixed size content layout area" isn't defined and up to a lot of interpretation

<alastairc> The output from publishing should still be covered

Exception: ("Except when a fixed size content layout area is essential to the information being conveyed.")

<alastairc> Don't see that this scenario is different from others? Grr. On a noisy train platform

Jason: setting of properties has been left out - bit looks OK

<Zakim> steverep_, you wanted to obect to that exception

steverep: Exception sounds possibly too broad - would data tables be covered?

<gowerm> Can someone provide an example of a page which needs this exception?

AWK: unless content in table is fixed size there is no reasong to exempt it

<alastairc> Don't understand the need. The technique for a fixed layout is to provide a small buffer around text

steverep: style properties changes may not effect for example powerpoint to the exception might not be applicable

Alex: agrees with this notion - is a fixed layout still an issue?

steverep: possibly where the markup language uses pagination and changes would not carry over to next page (?)

<gowerm> no exception

<laura> don’t need exception

AWK: So do we nned the exception?

<alastairc> No exception needed

<jallan> no exception

AWK: no one says exception is needed

Alex: perhaps reply to commenter that the advise is how this is implemented in the expanding universe of edocs etc - here we focus more narrowly
... In the future it might be implemented more broadly

<alastairc> Tricky to broaden because this whole ability needs a markup language approach. Eg Android might be able to cope, iOS trickier

Mike_Pluke: we are trying to make SCs general - so it avoids redrafting if it can cover three different contexts - so that makes the exception useful - would mean EN work need sto copy in WCAG language

AWK: So should we include exception?

goverm: which one?

<gowerm> I still don't like the exception -1

AWK: "Except when a fixed size content layout area is essential to the information being conveyed.")
... could EN work add exception?

<AWK> For approval: For content implemented using markup languages that support the following text style properties, then no loss of content or functionality occurs by setting all of the following and by changing no other style property.

<alastairc> Suggest an authoring exception drawn from atag instead

Mike_Pluke: yes WCAG text likely to be carried over plus exception

<Mike_Pluke> +1

AWK: so any objection to using this as response to 644 and 656?

<alastairc> +1

<AWK> For approval: For content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property.

(comments) a 'then' should be removed

<laura> +1

<JakeAbma> +1

RESOLUTION: accepted as amended

<AWK> Amended version: "For approval: For content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."

AWK: we are trying to speed things up so we shoul try to get this done this week - please respond quickly, use the list
... important is about 1.3.4 (Identify common controls) - most comments

- DRAFT -

Accessibility Guidelines Working Group Teleconference

09 Jan 2018

Attendees

Contents

Survey: https://www.w3.org/2002/09/wbs/35422/resolvingissues3/results

Issue 408

Issue 520

Issue 605

Issue 656

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output