
Korean: 
[음악 재생]
안녕하세요
저는 카시드 사디크이고
Android 접근성팀의 엔지니어입니다
본론으로 바로 들어가겠습니다
AndroidX와 머티리얼 등 저희가
제공하는 표준 위젯을 사용하는 경우
즉시 활용할 수 있는
기본 접근성 기능이 있습니다
접근성 작업은 꽤 쉬운 편이고
대부분 라벨을 추가하는 작업과
같은 것입니다
자체적으로 맞춤 위젯 또는
자체 UI 툴킷을 작성해야 하거나
이와 비슷한 경우라면
이야기가 조금 복잡해집니다
이때는 접근성을
대폭 향상할 필요가 있습니다
그 이유를 파악하기 위해
저희가 내부적으로 작업 중인
위젯 중 하나를 살펴보겠습니다
접근성 측면에서 말이에요
접근성 시스템에 대해
좀 더 이해하실 수 있을 겁니다
또한 작업을 하면서 부딪히게 되는
어려움도 파악하실 수 있고
예측하기 어려운 접근성 작업을
미리 파악하는 방법도
알게 되실 수 있습니다
시작하기 전에

Portuguese: 
Olá, pessoal.
Meu nome é Qasid Sadiq,
sou engenheiro da equipe
de acessibilidade do Android.
Indo direto ao ponto,
se você usa widgets padrão,
como os que fornecemos na plataforma
AndroidX e Material Design,
a acessibilidade é integrada
e é fácil realizar tarefas
de acessibilidade,
principalmente com a adição de rótulos.
Mas, se tem que criar os próprios
widgets personalizados ou o próprio
toolkit de IU ou algo assim,
essa história fica um
pouco mais complicada.
Você precisará de um trabalho
pesado com acessibilidade.
Para entender o motivo, vou mostrar
um dos widgets em que
trabalhamos internamente
em termos de acessibilidade.
Com isso, vocês entenderão um pouco mais
sobre o sistema de acessibilidade.
Conhecerão os desafios
que irão enfrentar ao
fazer esse tipo de trabalho,
e verão como definir o escopo
de acessibilidade antecipadamente,
porque pode ser imprevisível.

Japanese: 
Androidユーザー補助チームの
Qasid Sadiqです
早速始めましょう
Googleが プラットフォームやAndroidX、
マテリアルで提供する標準ウィジェットには
ユーザー補助機能が最初から組み込まれています
そのため 関連作業は簡単で
ラベルの付加などがほとんどです
しかし独自のカスタムウィジェットや
UIツールキットを作成する必要がある場合
話が少し複雑になり
手間のかかる作業になります
その理由を理解するため
社内開発したウィジェットの１つを
説明します
この説明を聞けば ユーザー補助システムの
理解が深まるでしょう
作業中に直面する課題についてや
予測しづらい作業範囲を
事前に定義する方法もわかります
本題に入る前に

English: 
[MUSIC PLAYING]
QASID SADIQ: Hey, guys.
My name is Qasid Sadiq and
I'm an engineer on the Android
Accessibility team.
So getting right into it,
if you use standard widgets,
like the ones that we provide
for you in the platform
AndroidX and
material, you're going
to have accessibility
built in out of the box.
And you're going to have
a pretty easy time doing
accessibility work, mostly
doing things like adding labels.
But if you have to
write your own custom
widgets or your own UI toolkit,
or anywhere in between,
that story is going to get a
little bit more complicated.
You're going to need
to do quite a bit
of the accessibility
heavy lifting.
So to understand why,
I'm going to walk you
through one of the widgets
that we worked on internally,
in terms of accessibility.
And, through this, you'll get
to understand a little bit more
about the accessibility system.
You'll get to understand
the challenges
that you're going to face when
you're doing this sort of work.
And you'll also
get to understand
how to scope accessibility work
beforehand, because that can
be a little bit unpredictable.
Now, before we get
into that story,

Spanish: 
Hola a todos.
Soy Qasid Sadiq, ingeniero
del equipo de Accesibilidad de Android.
Vamos directo al grano:
Si usan widgets estándares,
como los que les ofrecemos
en la plataforma, AndroidX y material,
podrán implementar accesibilidad integrada.
Y les resultarán más fáciles
las tareas de accesibilidad,
como agregar etiquetas.
Pero si escriben
sus propios widgets personalizados
en su kit de herramientas de IU,
o en otro lugar,
el proceso se volverá más complicado.
Deberán implementar
mucho contenido de accesibilidad.
Para entender la razón, les explicaré
uno de los widgets de accesibilidad
en los que trabajamos en la empresa.
De esta manera, comprenderán mejor
el sistema de accesibilidad,
los desafíos que deberán enfrentar
al hacer este tipo de trabajo
y cómo medir con anticipación
el alcance del trabajo de accesibilidad,
ya que puede ser impredecible.
Antes de meternos en tema,

Indonesian: 
[MUSIK DIPUTAR]
Halo, semua.
Saya Qasid Sadiq.
Saya engineer di tim
Android Accessibility.
Kita langsung saja.
Jika Anda menggunakan widget standar,
seperti yang kami berikan
di platform AndroidX
dan dalam materi,
Anda akan
memiliki aksesibilitas bawaan
yang siap pakai.
Pekerjaan aksesibilitas juga
lebih mudah dilakukan,
seperti menambahkan label.
Tapi, jika ingin menulis widget kustom
atau toolkit UI sendiri,
atau berbagai hal lainnya,
mungkin akan sedikit lebih rumit.
Anda harus melakukan pekerjaan
yang sulit dengan aksesibilitas
Agar paham alasannya,
saya akan bahas
satu widget yang kami kerjakan,
terkait aksesibilitas.
Anda juga akan sedikit
lebih memahami
sistem aksesibilitas.
Anda akan paham tantangan
yang muncul saat melakukan
pekerjaan ini.
Anda juga akan paham
cara menilai pekerjaan
aksesibilitas sebelumnya
karena bisa sedikit tak terduga.
Sebelum memulai,

English: 
let's talk about accessibility
at a high level real quick.
So there's your user
and that's your UI.
Your UI presents information
to the user, information
like the content that
they want, and information
on how to act on that UI.
The user takes that
and they act on your UI
to make it do things.
And that's a complete
user experience.
If any part of that is
broken, even subtly,
then your application is broken,
as far as a user is concerned.
Now, that seems simple enough.
But when you take into
account accessibility and all
the dramatically different
kinds of accessibility users
and the way that they
interact with the world,
things get a lot more
complicated, right?
Because we have all these
accessibilities and we
have variances in
the accessibilities.
We've also got combinations
of these accessibilities.
So we really don't expect
you, as app developers,
to figure out each and every
single one of these users,
make profiles for them, and
build a separate interface
for each of these users.
That'd be overwhelming
and a pretty good way
of creating an
awful accessibility
experience across applications.
Instead, what we have
is we have the concept
of an accessibility service.

Portuguese: 
Antes disso, vamos falar
sobre a acessibilidade de modo geral.
Então, aqui estão seu usuário e sua IU.
Sua IU tem informações ao usuário,
como o conteúdo que ele quer
e como usar essa IU.
O usuário as recebe e age na sua IU
para que ela faça as coisas.
É uma experiência completa.
Se uma parte disso falha,
mesmo que sutilmente,
o app também falha
no que se refere ao usuário.
Isso parece simples.
Quando você considera a acessibilidade,
os diferentes tipos de usuários
e a forma como eles
interagem com o mundo,
as coisas complicam um pouco mais.
Porque temos essas acessibilidades
e variações nelas.
Temos combinações dessas acessibilidades.
Não esperamos que vocês,
enquanto desenvolvedores de apps,
abranjam todos esses usuários,
gerem perfis para eles e criem
uma interface separada para cada um.
Seria cansativo e uma maneira de criar
uma péssima experiência de acessibilidade.
Em vez disso, o que temos é o conceito
de um serviço de acessibilidade.

Indonesian: 
mari kita bahas aksesibilitas
dengan sangat cepat.
Ini pengguna Anda dan
ini UI Anda.
UI menyajikan informasi
ke pengguna,
informasi seperti konten
yang mereka inginkan,
dan informasi cara bertindak
di UI tersebut.
Pengguna mengambil konten
dan bertindak di UI
agar melakukan sesuatu.
Itulah pengalaman pengguna lengkap.
Jika ada yang rusak,
sekecil apa pun
aplikasi kalian juga rusak,
jika pengguna menyadarinya.
Terlihat cukup sederhana.
Kalau Anda mempertimbangkan
aksesibilitas dan semua
jenis pengguna aksesibilitas
yang sangat berbeda
dan cara mereka berinteraksi
dengan dunia,
semuanya jadi semakin rumit, kan?
Karena kami punya semua
aksesibilitas
dan ada beragam aksesibilitas.
Kami juga punya kombinasi
aksesibilitas ini.
Jadi, kami sebagai developer aplikasi
tidak berharap Anda
menemukan setiap
pengguna ini,
membuatkan mereka profil, dan
membuat antarmuka terpisah
untuk tiap pengguna.
Akan sangat memberatkan
dan pengalaman
aksesibilitas yang dibuat
akan sangat buruk di seluruh aplikasi.
Sebaliknya, kami punya konsep
layanan aksesibilitas.

Spanish: 
hablemos rápidamente
sobre la accesibilidad en general.
Este es su usuario y esta es su IU.
La IU le muestra información al usuario,
por ejemplo, contenido que quiere ver,
y le indica cómo actuar en ella.
El usuario la toma y actúa en la IU
para que esta realice una acción.
Es una experiencia del usuario completa.
Si alguna parte falla, aunque sea un poco,
la aplicación no funciona
desde la perspectiva del usuario.
Parece algo simple,
pero al tener en cuenta la accesibilidad
y a los diversos tipos 
de usuarios de accesibilidad
y la forma en que interactúan con el mundo,
las cosas se complican, ¿no?
Porque tenemos todas estas
variaciones de accesibilidad
y también combinaciones de ellas.
No pretendemos
que los desarrolladores de apps
se encarguen de cada uno de estos usuarios,
creen perfiles especiales ni desarrollen
una IU separada para cada uno.
Eso sería abrumador y terminaría
en una terrible experiencia de accesibilidad
para cualquier aplicación.
En cambio, tenemos el concepto
de un servicio de accesibilidad.

Korean: 
접근성에 관해
간략하게 설명드리겠습니다
사용자와 UI가 있습니다
UI는 정보를 사용자에게 표시하죠
사용자가 원하는 콘텐츠나
UI 활용법에 대한 정보 같은 것을요
사용자는 그 정보를 받아들여
UI 작업에 적용합니다
바로 완전한 사용자 환경인거죠
UI 일부에 미미하게나마 문제가 생기면
사용자 측면에서는
애플리케이션에 문제가 생깁니다
간단해 보이죠
하지만 접근성 기능과
엄청나게 다양한 사용자 유형
그리고 사용자가 세상과 상호작용하는
방식을 고려해보면
훨씬 더 복잡해집니다
여러 종류의 접근성이 있고
접근성 간에 차이가 있기 때문입니다
접근성을 결합하여 사용하기도 합니다
저희는 그래서 앱 개발자가
사용자 전부를 각각 파악하고
사용자 프로필을 만든 후
각각에 맞는 개별 인터페이스를
구현할 것이라고 예상하지 않아요
개발자의 작업 부담이 과중해지며
애플리케이션의 접근성 환경 또한
나빠지기 때문입니다
이 대신 저희는 개념을 사용해요
접근성 서비스라는 개념이죠

Japanese: 
ユーザー補助機能の概要を
手短にお話しします
こちらがユーザーとUIです
UIは ユーザーに情報を提供します
ユーザーが求めるコンテンツや
そのUIに働きかける方法などです
ユーザーはその情報をもとに
UIに働きかけて処理を行わせます
一部にでも不具合があると
アプリが不完全だと判断されます
ごく単純なようですが
ユーザー補助機能を使うユーザーの場合
タイプや 周囲とやりとりする方法が
それぞれ大きく異なるため
はるかに複雑になります
機能は多種多様で
機能の中にも違いがあるからです
機能の組み合わせもあります
ですからアプリ開発者には
各ユーザーを理解して
個別にプロファイルやUIを作成する...
といったことは求められません
それでは 負荷が大きくなり
ユーザー補助機能の操作性は
ひどいものになるでしょう
代わりに ユーザー補助サービス
という概念を使います

English: 
Now, an accessibility
service is an application,
which takes the UI
presented and adjusts it
for a particular kind of user.
So, for example, TalkBack
is an accessibility service.
It takes information presented
visually and speaks out
loud to a user with
visual impairments.
Similarly, Switch
Access allows a user
with mobility impairments
to drive the whole UI
with a series of switches,
even as little as one.
Now, the way an
accessibility does this is it
consumes a generic
representation
of the information
presented on screen
through the
accessibility framework.
So your task, as
an app developer,
becomes pretty simple--
or simpler.
Make sure that every single
thing that your application
presents to the
user is expressed
to the accessibility service.
And make sure the
accessibility service
can act in your application
or your UI any way
that a user can.
So let's actually go a
little bit more in-depth,
in terms of this interface
between an application
and a user.
And we're going to break into
the lower levels of this.
There's three core
objects to this.

Indonesian: 
Kini, layanan aksesibilitas
adalah aplikasi,
yang menampilkan UI dan
menyesuaikannya
ke jenis pengguna tertentu.
Misalnya, TalkBack adalah
layanan aksesibilitas.
Yang mengambil informasi visual
dan membacakannya
ke pengguna
dengan gangguan penglihatan.
Seperti Switch Access,
memungkinkan pengguna
dengan gangguan mobilitas
menggerakkan seluruh UI
dengan rangkaian tombol,
meskipun hanya satu.
Aksesibilitas melakukannya dengan
menggunakan representasi generik
dari informasi di layar
melalui framework aksesibilitas.
Tugas Anda sebagai developer aplikasi
menjadi mudah,
atau lebih mudah.
Pastikan semua hal yang disajikan
aplikasi Anda ke pengguna
dinyatakan ke layanan aksesibilitas.
Dan pastikan layanan aksesibilitas
bisa bertindak di aplikasi atau UI
semau pengguna.
Mari sedikit lebih mendalami
antarmuka antara aplikasi
dan pengguna.
Kita akan masuk ke
level yang lebih rendah.
Ada tiga objek inti.

Korean: 
접근성 서비스란 애플리케이션입니다
UI를 표시하고 특정 유형의 사용자에게
맞춰 조정되죠
예를 들면 음성 안내 지원은
접근성 서비스 중 하나로
시각적으로 정보를 표시하고
시각 장애인에게는
큰 소리로 말을 해주죠
또한 스위치 제어의 경우
거동이 불편한 사용자가
전체 UI를 사용할 수 있게 해주죠
아주 작은 스위치를 포함한
스위치를 통해서 말이에요
접근성의 이러한 작동 방식은
화면에 전체적으로 표시되는 정보를
활용하는 것입니다
접근성 프레임워크를 통해서요
그렇기 때문에 앱 개발자의 업무가
간단해지거나
더 간단해지는 것이죠
애플리케이션에서 사용자에게
표시하는
모든 내용이 접근성 서비스에도
표현되도록 해야 합니다
또한 접근성 서비스는
사용자가 활동하는 것과
같은 방식으로
애플리케이션이나 UI에서
작동해야 합니다
이제 좀 더 깊은 내용을 다뤄보겠습니다
애플리케이션과 사용자 간
인터페이스라는
측면에서 말이죠
좀 더 상세하게 살펴보겠습니다
여기에는 핵심 주제 세 가지가 있어요

Spanish: 
Se trata de una aplicación
que toma la IU presente y la ajusta
para un tipo de usuario en particular.
Por ejemplo, TalkBack
es un servicio de accesibilidad
que toma la información presentada
visualmente y la recita en voz alta
a los usuarios con discapacidad visual.
Por otro lado, Accesibilidad mejorada
permite que un usuario
con movilidad reducida controle la IU
con una serie de interruptores,
o incluso uno solo.
Para ofrecer esta capacidad,
la accesibilidad consume
una representación genérica
de la información en pantalla
mediante el marco de trabajo
de accesibilidad.
Entonces, su tarea
como desarrolladores de apps
se vuelve más simple.
Asegúrense de que cada aspecto
que su aplicación presente al usuario
se exprese al servicio de accesibilidad
y de que ese servicio
pueda actuar en su aplicación o IU
de todas las formas
en las que puede hacerlo el usuario.
Vamos a profundizar un poco
sobre esta interfaz
que une al usuario con la aplicación.
Vamos a desglosar la información en niveles.
Hay tres objetos principales.

Japanese: 
これは アプリで表示中のUIを取り込んで
特定のタイプのユーザーに合わせるものです
たとえば TalkBackは
表示されている情報を取り込んで
視覚障がいのあるユーザーに読み上げます
スイッチアクセスは
運動障がいのあるユーザー向けで
１つまたは複数のスイッチで
UI全体を操作できます
このような機能を実現するには
ユーザー補助フレームワークによって
画面に表示されている情報の
汎用的な表現を利用します
するとアプリ開発者の作業は
かなりシンプルになります
アプリがユーザーに提供する
すべての情報を
ユーザー補助サービスに示してください
このサービスがユーザー同様に
UIに働きかけられるようにします
アプリとユーザーの
インターフェースをもう少し掘り下げてから
さらに詳細な内容に進みます

Portuguese: 
Um serviço de acessibilidade é um app
que pega a IU apresentada e a ajusta
para um tipo específico de usuário.
Por exemplo, TalkBack é um
serviço de acessibilidade.
Ele pega as informações apresentadas
visualmente e as lê em voz alta
para um usuário com deficiências visuais.
E, com o acesso com interruptor,
o usuário com deficiências de mobilidade
pode ativar toda a IU com interruptores.
A forma como a acessibilidade faz isso é
consumindo uma representação genérica
das informações apresentadas na tela
por meio do framework de acessibilidade.
Para os desenvolvedores,
a tarefa é bem simples.
Ou ainda mais simples:
ter a certeza de que tudo o que seu app
apresenta ao usuário é enviado
ao serviço de acessibilidade
e garantir que esse serviço
aja no app ou na IU de modo
acessível ao usuário.
Vamos nos aprofundar um pouco
em termos dessa interface
entre app e usuário.
Vamos analisar os níveis inferiores.
Há três objetos centrais aqui.

English: 
The first one is an
accessibility node info.
Accessibility node
info represents
what's currently on screen.
Each accessibility node info
typically, but not always--
there's a few notable
exceptions-- corresponds
to a view.
It captures information like its
position on screen, the text,
the content description
associated with it,
what you can do to the view,
and a bunch of other stuff
related to state
and other things.
You can see that, once we take
into account parent and child
relationships, you'll have a
node tree similar to a view
hierarchy.
And you can see that the
accessibility service
through this will have a pretty
good understanding of all
of the information
presented on screen.
So now that the
accessibility service
can query for what's on screen,
it needs to know when to query.
And that comes from an
accessibility event.
This is something that's
sent from the application
to the accessibility service
whenever a change happens
within your UI.
Let me walk you
through an example.
Let's look at this view
hierarchy on the left
and the node tree on the right.
And let's focus on that
green highlighted view.
So if something
changes in that view,
like if some view is removed,
an accessibility event

Japanese: 
重要なオブジェクトの１つ目は
AccessibilityNodeInfoです
これは 画面上に表示中の情報を表します
いくつかの注目すべき例外はありますが
通常は それぞれ
１つのビューに対応しています
画面上の位置、テキスト、
コンテンツに関連付けられている説明、
ビューに対して行える操作、
状態などに関連する要素
といった情報を取り込みます
親子関係を考慮すると
ビュー階層に似たノードツリーに
なることがわかります
ユーザー補助サービスは
このノードツリーを通じて
画面に表示された
すべての情報を理解できます
次に 画面上の情報をクエリするための
タイミングを知らせるのが
AccessibilityEventです
これは UI内で変更が発生するたびに
アプリから
ユーザー補助サービスに送信されます
例を説明します
左のビュー階層と
右のノードツリーを見てください
緑色でハイライトされたビューに注目します
ビューが削除されるなどの変更が発生すると

Portuguese: 
O primeiro é AccessibilityNodeInfo.
Ele representa
o que está na tela no momento.
Normalmente, mas com algumas exceções,
um AccessibilityNodeInfo
corresponde a uma visualização.
Ele captura informações como
posição na tela, o texto,
a descrição do conteúdo associada,
o que você pode fazer na
visualização e outras coisas
relacionadas a estados etc.
Vejam que, se considerarmos uma
relação pai/filho, teremos uma
árvore de nós semelhante a uma
hierarquia de visualizações.
O serviço de acessibilidade
terá um bom entendimento de todas
as informações apresentadas na tela.
Agora que o serviço de acessibilidade
pode consultar a tela,
ele precisa saber quando fazer isso.
Isso vem de AccessibilityEvent.
É algo que é enviado do app
ao serviço de acessibilidade sempre
que ocorre uma mudança na IU.
Vamos ver um exemplo.
Vejamos a hierarquia à esquerda
e a árvore à direita.
Vamos focar nessa visualização
destacada em verde.
Se algo muda nessa visualização,
por exemplo, se ela é removida,
um evento de acessibilidade

Indonesian: 
Pertama, info node aksesibilitas.
Info node aksesibilitas mewakili
apa yang ditampilkan di layar.
Setiap info node aksesibilitas
biasanya, tapi tidak selalu,
ada beberapa pengecualian penting,
sesuai dengan tampilan.
Objek ini mengambil informasi
seperti posisinya di layar, teks,
deskripsi konten terkait,
yang bisa Anda lakukan pada tampilan,
dan banyak hal lain
terkait status dan hal lainnya.
Anda bisa lihat,
saat kami pertimbangkan hubungan
induk dan turunan,
akan ada pohon node
yang mirip hierarki tampilan.
Dan layanan aksesibilitas melalui ini
akan punya pemahaman yang baik
tentang semua informasi di layar.
Jadi, jika bisa meng-kueri
apa yang ada di layar,
layanan aksesibilitas
harus tahu kapan saatnya.
Ini berasal dari peristiwa aksesibilitas.
Sesuatu yang dikirim
dari aplikasi
ke layanan aksesibilitas
setiap kali ada perubahan dalam UI
Saya akan memberi satu contoh.
Lihat hierarki tampilan ini di kiri
dan pohon node di kanan.
Fokus pada tampilan berwarna hijau.
Jika ada yang berubah pada tampilan ini.
seperti jika ada tampilan dihapus,
peristiwa aksesibilitas

Spanish: 
El primero es AccessibilityNodeInfo.
Este representa el contenido
de la pantalla en el momento.
Cada uno de estos generalmente, 
pero no siempre,
ya que existen algunas excepciones,
corresponde a una vista.
Captura información,
como la posición en la pantalla, el texto,
la descripción del contenido asociado,
lo que pueden hacer con la vista
y otros datos relacionados
con el estado y otros aspectos.
Una vez que tenemos en cuenta 
las relaciones principal-secundario,
logramos un árbol de nodos
similar a una vista jerárquica.
Y pueden ver que el servicio de accesibilidad
que lo atraviesa comprenderá
toda la información
presentada en la pantalla.
Ahora que el servicio
puede solicitar el contenido en pantalla,
debe saber cuándo hacerlo.
Para ello,
están los AccessibilityEvent.
Los eventos se envían desde la aplicación
al servicio de accesibilidad
cuando ocurre un cambio en la IU.
Les mostraré un ejemplo.
Miren la vista jerárquica a la izquierda
y el árbol de nodos a la derecha.
Enfóquense en la vista verde destacada.
Si algo cambia en esa vista,
por ejemplo, si que quita una parte,
se enviará un evento de accesibilidad

Korean: 
첫 번째는 접근성 노드 정보입니다
접근성 노드 정보란
현재 화면에 표시된 것을 의미합니다
접근성 노드 정보 각각은 대개
뷰에 해당합니다
물론 항상 그런 것은 아니고
예외도 있긴 합니다
화면상의 위치, 텍스트,
관련 콘텐츠 설명
뷰에서 할 수 있는 작업 등의 정보,
그리고 상태나 기타 사항에 대한
정보를 캡처합니다
보시는 것처럼
상위와 하위 관계를 고려하면
노드 트리가 생기고
이는 뷰 계층 구조와
유사하죠
이를 통해 접근성 서비스는
화면상에 표시된 정보를
파악할 수 있게 됩니다
접근성 서비스가 화면에
표시된 것에 대해
쿼리를 실행할 수 있으므로
이제 쿼리를 실행하는 시기를
알아야 하는데
접근성 이벤트에 답이 있습니다
UI 내에서 변경이 발생할 때마다
애플리케이션이 접근성 서비스로
전송하는 것이
접근성 이벤트입니다
예를 들어 보죠
왼쪽에 뷰 계층 구조가 있고
오른쪽에 노드 트리가 있습니다
초록색으로 강조된 뷰를 보겠습니다
뷰에서 무언가 변경이 된다면
예를 들어 뷰가 삭제된다는 등 말이에요

Indonesian: 
dikirim dari tampilan yang ditandai.
Layanan aksesibilitas
tahu cara membatalkan
bagian hierarki pohon node
dan meng-kueri
yang baru.
Ada representasi yang diperbarui
terkait informasi yang disajikan
ke pengguna.
Saat ini, layanan aksesibilitas
memiliki representasi yang akurat
tentang apa yang ada di layar.
Tapi, yang tidak ada saat ini adalah
kemampuan layanan aksesibilitas
untuk bertindak di UI,
biasanya atas nama pengguna.
Ada di tindakan aksesibilitas,
yang merupakan
objek yang memetakan ID tindakan
secara efektif,
yang bisa jadi sesuatu seperti
tindakan standar
seperti meng-scroll, mengklik, atau
menekan lama,
pada bit kode yang ingin dijalankan
saat sesuatu seperti itu terjadi.
Dengan bagian inti ini,
kita bisa mulai berbicara
tentang materi utamanya,
yaitu ViewPager2,
widget yang akan
kita bahas hari ini.
Beberapa bulan lalu,
dua rekan saya,
Jel dan Jacob,
memutuskan
untuk membuat versi ViewPager
yang baru, yang tidak terikat
masalah yang tidak bisa diselesaikan
di ViewPager1,

English: 
is sent from the
highlighted view.
The accessibility service
knows to invalidate
that part of the
node tree hierarchy
and query for a new one.
And now it has the
updated representation
of what information is
being presented to the user.
Now, at any given moment,
the accessibility service
has an accurate representation
of what's on screen.
But what's missing,
at this point,
is the ability for the
accessibility service
to act on your UI, typically
on behalf of the user.
That's captured in an
accessibility action, which
is an object which effectively
maps an action ID, which
could be something
like a standard action,
like scrolling, or clicking, or
long pressing, to a bit of code
that you want executed when
something like that happens.
So with these core
pieces, we can
start talking about
the main story, which
is ViewPager2, which
is a widget we're
going to talk through today.
So several months ago, a
couple of my colleagues,
Jel and Jacob,
decided that they're
going to make a new version
of ViewPager, one not tied
to the issues that ViewPager1
is stuck to, partially

Japanese: 
ハイライトされたビューから
AccessibilityEventが送信されます
ユーザー補助サービスは
更新部分をノードツリー階層で無効にして
新たにクエリします
こうして ユーザーに提供されている情報の
最新の表現を取得しました
ユーザー補助サービスはいつでも
画面上の情報の正確な表現を保持しています
しかしこれだけでは ユーザーに代わって
UIに働きかけることはできません
その役割を果たすのが
AccessibilityActionです
これは スクロール、クリック、
長押しなどの標準アクションのIDを
アクションの発生時に実行させるコードへと
マッピングするオブジェクトです
これらの重要な要素を使って
本題であるウィジェット「ViewPager2」
について話していきます
数か月前
同僚のJelとJacobが
ViewPagerの新バージョンを
作成することになりました
RecyclerVewの機能と柔軟性を
利用することで

Spanish: 
de la vista destacada.
El servicio de accesibilidad
sabe que debe invalidar esa parte
de la jerarquía del árbol de nodos
y solicitar una nueva.
Ahora, tiene la representación actualizada
de la información
que se le presenta al usuario.
Ahora, en cualquier momento,
el servicio de accesibilidad
tendrá una representación precisa
del contenido en pantalla.
Pero lo que falta en este punto
es la capacidad
para que el servicio de accesibilidad
actúe sobre la IU en nombre del usuario.
Eso se captura en AccessibilityAction,
que es un objeto que mapea
un ID de acción de manera efectiva,
por ejemplo, una acción estándar,
como desplazarse,
hacer clic o mantener presionado,
al fragmento de código
que quieran ejecutar en un caso como ese.
Con estas piezas fundamentales,
podemos empezar a hablar del tema principal,
que es ViewPager2, el widget
sobre el que hablaremos hoy.
Hace varios meses, dos de mis colegas,
Jel y Jacob, decidieron crear
una nueva versión de ViewPager
que no tendrá los problemas de ViewPager1,

Korean: 
그럼 접근성 이벤트가 강조된 뷰에서
전송됩니다
접근성 서비스는
노드 트리 계층 구조의 일부를
무효화하고
새로운 것에 대한 쿼리를
실행할 수 있습니다
이제 사용자에게
업데이트된 정보가 표시됩니다
이제 접근성 서비스는 언제든지
화면상에 정확한 정보를
표시할 수 있습니다
여기에서 한 가지 언급할 것은
접근성 서비스가 주로 사용자 대신
UI에서 액션을 취하는 기능입니다
이러한 기능은 접근성 액션에 캡처되죠
액션 ID를 효율적으로 매핑하는 객체로
표준 액션이라고 할 수 있겠네요
스크롤하기, 클릭하기,
길게 누르기 같은 액션 말이에요
이러한 액션이 발생할 때 실행하고자
하는 코드에 액션 ID를 매핑하는 거죠
이 핵심 내용을 바탕으로
오늘의 주제인
ViewPager2라는 위젯에 대해
알아보겠습니다
몇 개월 전 제 동료인
젤과 제이콥은
ViewPager1의 문제와 관련 없는
ViewPager의 새로운 버전을
만들기로 했습니다

Portuguese: 
é enviado a partir
da visualização destacada.
O serviço de acessibilidade sabe invalidar
essa parte da hierarquia da árvore de nós
e consultar uma nova.
Agora ele tem a representação atualizada
das informações que estão sendo
apresentadas ao usuário.
Em dado momento,
o serviço de acessibilidade
tem uma representação exata
do que está na tela.
Nesse ponto, o que está faltando
é a capacidade de o serviço
agir na sua IU, normalmente
em nome do usuário.
Isso é capturado em
AccessibilityAction,
que é um objeto que mapeia
o ID de uma ação,
que poderia ser algo como
uma ação padrão,
por exemplo, rolar, clicar, tocar e manter
pressionado, para um código
que será executado
quando algo assim acontecer.
Com esses elementos principais, podemos
começar a falar
sobre o tópico principal,
que é o ViewPager2,
um widget que vamos analisar hoje.
Há alguns meses, dois colegas,
Jel e Jacob, decidiram que iriam
criar uma nova versão do ViewPager que
não tivesse os mesmos problemas
do ViewPager1, em parte

Japanese: 
ViewPager1で未解決の問題に
縛られなくなります
彼らは賢明なことに
開発プロセスのかなり早い段階で
私たちに ユーザー補助機能についての
手助けを依頼してきました
同僚のSallyが名乗りを上げ
すぐに取り組み始めました
ViewPagerとは何かをまず理解しましょう
ひと続きのページを
めくることができるビューです
ビューそのものや階層、フラグメントなど
何でもページにすることができます
この機能の核は ユーザーがページを
めくれるようにすることなので
ここから始めましょう
ユーザーがページ間を移動できる機能を
ユーザー補助サービスに
公開する必要があります
これはユーザーのアクションを取り込む
AccessibilityActionによって実現可能です
そこで使うのは 高水準APIの
viewCompat.replaceAccessibilityActionです
そしてこのアクションの標準動作である

Portuguese: 
porque iriam utilizar
os recursos e a flexibilidade
de RecyclerView.
Eles fizeram a coisa certa e,
no início do
processo de desenvolvimento,
falaram com a equipe de acessibilidade,
da qual faço parte,
e nos pediram ajuda
para criar acessibilidade.
Uma colega disse:
"Podemos fazer isso."
Ela entrou de cabeça.
Este é o trabalho que ela fez.
Antes de qualquer coisa,
precisamos entender
o que é um ViewPager.
Ele é uma visualização
quer permite que você
navegue por uma série de páginas.
As páginas podem ser visualizações,
hierarquias, fragmentos
ou outros elementos.
E como essa funcionalidade
permite a navegação por uma página,
podemos começar aqui
em termos de acessibilidade.
Queremos expor a capacidade
de um usuário ir de uma página
para outra ao serviço de acessibilidade.
Isso pode
ser feito por meio de algo
como uma AccessibilityAction,
que captura ações do usuário.
Vamos usar a API de nível superior,
ViewCompat.replaceAccessibilityAction.

Spanish: 
en parte porque usarán la tecnología
y la flexiiblidad de RecyclerView.
Hicieron lo correcto y,
en las primeras fases de desarrollo,
contactaron al equipo de Accesibilidad,
en el que trabajamos mis colegas y yo,
y nos preguntaron si podíamos
ayudarlos a desarrollar accesibilidad.
Una colega, Sally, dijo que sí.
Y se comprometió completamente.
Este fue su trabajo.
Antes de seguir,
debemos comprender qué es ViewPager.
Es una vista que les permite
pasar una serie de páginas.
Estas páginas pueden ser vistas,
jerarquías, fragmentos
o cualquier elemento que quieran.
Como la parte principal de esta función
es permitirle al usuario pasar de página,
pueden empezar
a trabajar en accesibilidad por ahí.
Queremos habilitar
en el servicio de accesibilidad
la opción para que el usuario
pase de una página a la siguiente.
Recuerden que, para ello,
pueden usar una acción de accesibilidad
que capture las acciones del usuario.
Usaremos una API general:
viewcompat.replaceaccessibilityaction,
y anularemos 
el comportamiento estándar de la acción:

Korean: 
바로 RecyclerView의 강력한
이점과 유연성을
활용하기 위해서였죠
두 사람은 개발 초기 단계에서
저와 동료들이 속한
접근성팀에 찾아와서
ViewPager의 접근성과 관련해
도움을 줄 수 있는지
물었습니다
제 동료 중 샐리가 당연히 돕겠다고 했죠
샐리는 바로 작업에 돌입했습니다
이게 샐리가 한 일이죠
가장 먼저 알아야 할 것은
ViewPager가 무엇이냐는 것입니다
ViewPager는 페이지를 전환하게 해주는
뷰입니다
페이지는 뷰 자체일 수 있고
계층 구조, 프래그먼트 등 무엇이든
될 수 있습니다
핵심 기능은 사용자가 페이지를
전환하도록 하는 것이기 때문에
접근성 측면에서부터 시작해보겠습니다
저희의 목표는 사용자가
페이지를 전환할 수 있는 이 기능을
접근성 서비스에서 제공하는 것입니다
이는 사용자 액션을 캡처하는
접근성 액션과 같은 것을 통해
가능합니다
그렇기 때문에 상위 수준 API인
viewcompat.replaceaccessibilityaction을
사용하고자 합니다
또한 액션에 필요한 표준 동작인

English: 
because they're going to utilize
the power and the flexibility
of RecyclerView.
And they did the right
thing and, very early
on in the development
process, they
approach the accessibility team,
which is me and my colleagues,
and they asked us,
hey, can you guys
help us to
accessibility for this?
And one of my colleague, Sally,
said, yeah, of course I can.
And she jumped right into this.
This is the work that she did.
So before anything else,
we need to understand
what a ViewPager is.
It's effectively a view
that allows you to flip
through a series of pages.
These pages can be
views themselves,
hierarchies, fragments,
whatever you expect.
And because the way the
core of this functionality
is allowing you the user
to flip through a page,
we can start there, in
terms of accessibility.
We want to expose the ability
for a user to go from one page
to another to the
accessibility service.
If you remember, that can
be done through something
like an accessibility action,
which captures user actions.
So we're going to use the high
level API, viewcompat.repla
ceaccessibilityaction.
And we're going to take--

Indonesian: 
sebagian karena akan menggunakan
kehebatan dan fleksibilitas RecyclerView.
Mereka melakukan hal yang benar,
di awal proses pengembangan,
mereka mendekati tim aksesibilitas,
yakni saya dan rekan saya.
Mereka bertanya apa kita bisa
bantu soal aksesibilitas?
Salah satu teman saya, Sally,
bilang, tentu.
Dan dia langsung melakukannya.
Karena itu pekerjaannya.
Sebelumnya, kita harus paham
apa itu ViewPager.
Secara efektif, ini adalah tampilan
agar Anda bisa membolak-balik
serangkaian halaman.
Halaman ini bisa jadi tampilan
itu sendiri, hierarki, fragmen,
apa pun yang Anda inginkan.
Karena cara inti fungsi ini
memungkinkan Anda
membolak-balik halaman,
kita bisa mulai dari sana,
dalam hal aksesibilitas.
Kami ingin pengguna bisa
membuka halaman demi halaman
dengan layanan aksesibilitas.
Kalau Anda ingat, hal ini bisa dilakukan
melalui tindakan aksesibilitas,
yang menangkap tindakan pengguna.
Kami akan menggunakan API tingkat tinggi,
viewcompat.replaceaccessibilityaction.
Dan akan mengganti

Korean: 
accessibility scroll backward를
재정의하려 합니다
이 특정한 뷰에 대해서도
재정의가 필요하죠
이렇게 하면 사용자가 이 뷰에서
접근성 서비스에 뒤로 스크롤하기를
요청할 때마다
여기 있는 이 코드나 람다가
호출되어 기본적으로
페이지 수를 기록하죠
setCurrentItem은 현재 페이지를
설정합니다
Action_ Scroll_Forward에도
적용하면 됩니다
updatePageAccessibilityActions 함수를
보겠습니다
on initialize라고 부르죠
ViewPager에 이렇게 나타납니다
이제 ViewPager 관련
접근성 노드 정보에
두 가지 커스텀 액션이 생겼습니다
accessibility scroll backward와
accessibility scroll forward입니다
좋아요
그런데 첫 번째 페이지로 넘기면
action scroll backward가
아직 남아 있습니다
사용자는 뒤로 스크롤할 수 없고
서비스에서도 불가능하기
때문에 말이 안 되죠
그래서 여기에 조건을 추가합니다
첫 번째 페이지에서는
action scroll backward를 추가하지 않고
마지막 페이지에서는
action scroll forward를 추가하지 않고요
액션 상태는 뷰나 항목의 상태의

Portuguese: 
E vamos substituir o comportamento
padrão da ação, rolar para trás.
Vamos substituir nessa
visualização específica.
Sempre que o usuário pede
ao serviço de acessibilidade
para rolar algo para trás
nessa visualização,
o código ou o lambda será chamado,
o que, basicamente,
reduz a contagem de páginas.
Define o item atual,
define a página atual.
Agora podemos ter também
ações de rolar para a frente.
Vamos lançar em uma função
updatePageAccessibilityActions.
Vamos chamar na inicialização
para que esteja no ViewPager.
O AccessibilityNodeInfo associado a esse
ViewPager tem duas ações personalizadas:
rolar para trás e para a frente.
Mas, se navegar para a primeira página,
a ação de rolar para trás está lá.
Não é bem isso, porque
um usuário não pode rolar para trás,
nem o serviço pode fazer isso.
Vamos adicionar uma condição aqui.
Não vamos adicionar a ação de
rolar para trás na primeira página.
Nem a de
rolar para a frente na primeira página.
Como nosso estado de ações

Japanese: 
ACTION_SCROLL_BACKWARDを
オーバーライドします
このビューに対してオーバーライドします
このビュー上の何かを後方スクロールするよう
ユーザー補助サービスに要求するたびに
このコードつまりラムダが呼び出されます
これは基本的に
ページ数を記録するものです
setCurrentItemは
現在のページを設定します
前方スクロールも同様です
これを関数updatePageAccessibilityActionsに
投入して
初期化などの際に呼び出すと
ViewPagerに対して有効になります
このViewPagerに関連付けられた
AccessibilityNodeInfoには
ACTION_SCROLL_BACKWARDと
ACTION_SCROLL_FORWARDの
２つのカスタムアクションができました
しかし先頭ページまでめくっても
まだACTION_SCROLL_BACKWARDがあります
ユーザーは後方スクロールできないので
補助サービスもそうあるべきです
そこで条件を追加します
先頭ページには
ACTION_SCROLL_BACKWARDを追加せず
最終ページにはACTION_SCROLL_FORWARDを
追加しないようにします
アクションの状態は
ビューやアイテムの状態に依存しないので

Indonesian: 
perilaku standar untuk tindakan,
scroll aksesibilitas mundur.
Kami akan menggantinya
untuk tampilan tertentu ini.
Kapan pun pengguna meminta
layanan aksesibilitasnya
untuk scroll mundur sesuatu
dalam tampilan ini,
kode ini atau lambda ini
akan dipanggil,
yang pada dasarnya
mendokumentasikan jumlah halaman.
Mengatur item saat ini,
mengatur halaman saat ini.
Kita bisa scroll maju.
Mari langsung bahas tindakan aksesibilitas
halaman update fungsi.
Dan kita akan memanggil ini
di awal,
jadi bisa ada di ViewPager.
Info node aksesibilitas
dengan ViewPager ini
punya dua tindakan kustom di dalamnya,
scroll aksesibilitas mundur,
dan scroll aksesibilitas maju.
Bagus.
Tapi, jika Anda balik ke
halaman pertama,
scroll tindakan mundur 
masih ada.
Agak kurang tepat, karena
pengguna tidak bisa scroll mundur,
begitu juga dengan layanan.
Kita akan tambahkan
ketentuan di sini.
Jangan tambahkan scroll tindakan
mundur di halaman pertama.
Jangan tambahkan scroll akses maju
di halaman terakhir.
Dan karena tindakan kita tidak

Spanish: 
ACCESIBILITY_SCROLL_BACKWARD.
También lo anularemos
para esta vista en particular.
Entonces, cuando el usuario
le solicite al servicio de accesibilidad
que se desplace hacia atrás en esta vista,
se llamará a este código o esta lambda,
que documentará el recuento de páginas.
setCurrentItem establecerá la página actual.
Ahora, para el desplazamiento hacia adelante,
usaremos la función
updatePageAccessibilityActions.
Llamaremos a initialize o algo similar
para que se muestre en ViewPager.
Ahora, el AccessibilityNodeInfo
asociado con este ViewPager
tiene dos acciones personalizadas:
ACCESSIBILITY_SCROLL_BACKWARD
y ACCESSIBILITY_SCROLL_FORWARD.
Genial.
Pero si vuelven a la primera página,
todavía está ACTION_SCROLL_BACKWARD,
aunque no funciona,
porque el usuario no puede ir atrás
y el servicio tampoco debería poder hacerlo.
Ahora, agregaremos una condición.
Quitaremos ACTION_SCROLL_BACKWARD
de la primera página
y ACCESS_SCROLL_FORWARD de la última página.
Como nuestro estado de acciones

English: 
override the standard
behavior for the action,
accessibility scroll backward.
And we're going to override
it for this particular view.
So whenever the user asks
its accessibility service
to scroll something
backward on this view,
this code over
here or this lambda
is going to be called,
which fundamentally
documents the page count.
Set current item,
sets the current page.
Now, we can do for actions
scroll forward also.
Let's throw this into
a function update page
accessibility actions.
And we'll call this on
initialize or something,
so this exists on the ViewPager.
Now, the accessibility node info
associated with this ViewPager
has these two custom
actions on it,
accessibility scroll backward
and accessibility scroll
forward.
That's great.
But, if you flip
to the first page,
action scroll backward
is still there.
This is a bit of a lie, because
a user can't scroll backward
and neither should the
service be able to either.
So we're going to add
a condition to this.
Let's not add an action scroll
backward on the first page.
Let's not add an access scroll
forward on the last page.
And because our state
of actions is not

Indonesian: 
bergantung pada tampilan atau item,
mari hapus semua tindakan ini
sebelum menambahkannya lagi,
jadi tidak ada yang menganggur.
Mari panggil tindakan aksesibilitas
halaman update
di set item saat ini,
karena statusnya dependen.
Kini, tindakan dicerminkan
dengan tepat
berdasarkan nomor halaman.
ViewPager juga punya
orientasi vertikal atau
konsep orientasi.
Dan ada poin yang menarik.
Meski secara teknis
tindakan scroll maju
dan scroll mundur
memungkinkan Anda
menggunakan ViewPager
di mode vertikal,
dan sangat masuk akal,
masih ada yang hilang di sini,
yaitu konsep arah yang mutlak.
Layanan aksesibilitas tertentu
sangat memperhatikan hal ini.
Seperti, seseorang menggerakkan UI
melalui suara
bisa bilang scroll ke atas
atau scroll ke bawah.
Ini jelas disajikan ke pengguna
dengan cara yang hampir tak terlihat.
Jadi, kita harus menyajikannya
ke layanan aksesibilitas.
Kita akan tambahkan beberapa
tindakan, agar
pengguna dapat membalik
halaman ke arah pasti.
Dan muncul di halaman tindakan
atas dan bawah atau kiri dan kanan,
tergantung orientasinya.

English: 
dependent on the state
of the view or the item,
let's clear out any
of these actions
before we add them
again, so we don't
leave anything stale on it.
And let's call update
page accessibility actions
on set current item, because
that's a dependent state.
Now, the actions are
correctly reflected
based on the page number.
Now, ViewPager also
has something--
also has a vertical orientation
or a concept of orientation.
And this brings up
an interesting point.
Although, technically,
action scroll forward
and scroll backward
still allow you
to use a ViewPager in
a vertical fashion,
and it makes complete
sense, there's
still something
missing here, which
is a concept of
absolute direction.
Certain accessibility services
care a lot about this.
Like, someone driving their
UI through their voice
may say scroll up
or scroll down.
And this is something
that's obviously
presented to the user
in a very subtle way.
So we have to present it to
the accessibility service.
So we're going to add
some actions, which
allow the user to flip through
pages in an absolute direction.
And that comes in action page
up and down or left and right,
depending on the orientation.
And, again, we do
the same thing.
We invalidate the
actions beforehand,

Portuguese: 
não depende do estado da
visualização ou do item,
vamos eliminar qualquer
uma dessas ações
antes de adicioná-las
novamente.
Não deixamos nada desatualizado.
Vamos chamar
updatePageAccessibilityActions
em setCurrentItem,
porque é um estado dependente.
Agora, as ações são
refletidas corretamente
com base no número da página.
O ViewPager também tem orientação vertical
ou um conceito de orientação.
Isso traz um ponto interessante.
Embora as
ações de rolar para a frente
e rolar para trás
também permitam que você
use um ViewPager na vertical,
o que faz bastante sentido,
ainda falta algo,
um conceito de direção absoluta.
Alguns serviços de acessibilidade
cuidam disso.
Por exemplo, uma pessoa
acionando IU por voz
pode dizer "rolar para cima"
ou "rolar para baixo".
Isso é claramente
apresentado ao usuário
de maneira bem sutíl.
Temos que apresentá-lo
ao serviço de acessibilidade.
Vamos adicionar algumas ações
para o usuário navegar
pelas páginas em uma direção absoluta.
Isso está em ACTION_PAGE_UP,
DOWN, LEFT e RIGHT. Depende da orientação.
Vamos fazer a mesma coisa:
invalidamos as ações antes

Spanish: 
no depende del estado de la vista
ni del elemento,
borraremos todas estas acciones
antes de volver a agregarlas
para no dejar nada inactivo.
Llamaremos acciones
de updatePageAccessibility
en setCurrentItem
porque es un estado dependiente.
Ahora, las acciones se reflejan correctamente
según el número de página.
ViewPager también cuenta
con orientación vertical,
o más bien un concepto de orientación.
Aquí, sucede algo interesante.
Aunque, técnicamente, ACTION_SCROLL_FORWARD
y ACTION_SCROLL_BACKWARD
les permiten usar ViewPager
en orientación vertical y tiene sentido,
todavía falta algo,
que es el concepto de dirección absoluta.
Algunos servicios priorizan este concepto.
Por ejemplo, alguien que está conduciendo
puede desplazarse
arriba o abajo en la IU con la voz.
Obviamente, esta opción
se le presenta al usuario de manera sutil.
Por eso, para presentarla
al servicio de accesibilidad,
agregaremos algunas acciones
que le permitan al usuario
desplazarse en dirección absoluta.
Usaremos ACTION_PAGE_UP y DOWN
o LEFT y RIGHT, según la orientación.
Repetimos el proceso.

Korean: 
영향을 받지 않기 때문에
여기 있는 액션을
다시 추가하기 전에 다 지워서
쓸데없는 것이 남지 않도록 합니다
현재 설정된 항목에
updatePageAccessibilityActions을
호출해 봅시다
의존 상태이기 때문이죠
이제 액션이 페이지 숫자에 따라
제대로 반영되었습니다
ViewPager에는
세로 방향 또는 방향 개념이 있습니다
여기에 흥미로운 점이 있죠
기술적으로는 action scroll forward와
scroll backward를 사용하더라도
ViewPager를 세로 방향으로
사용할 수 있고
아무런 문제가 없지만
절대 방향이라는 개념은
빠져 있습니다
특정 접근성 서비스는 이 부분에
주목합니다
목소리를 통해 UI를 작동시키는 사람은
위로 스크롤 또는 아래로
스크롤하라고 말할 수 있어요
사용자에게는 아주
섬세한 방식으로 표시되는 거죠
그래서 저희는 이 방법을
접근성 서비스에도 나타내야 합니다
일부 액션을 추가할 겁니다
사용자가 절대 방향이
적용된 페이지를 전환하도록 말이죠
ACTION_PAGE_UP과 DOWN 또는 LEFT와 RIGHT가
방향에 따라 필요합니다
아까와 마찬가지입니다
이전 액션을 무효화하고

Japanese: 
これらのアクションは
再度追加する前に取り除きましょう
これで 古い情報が残りません
依存関係状態にあるので
setCurrentItemで
updatePageAccessibilityActionsを
呼び出します
アクションがページ番号に基づいて
正しく反映されました
ViewPagerには縦向き
つまり方向の概念もあります
このことは興味深い問題を提起します
技術的には
ACTION_SCROLL_FORWARDと
ACTION_SCROLL_BACKWARDは
縦向きのViewPagerでも使用でき
問題なく機能しますが
絶対方向という概念が欠けています
サービスによっては重要な概念です
音声でUIを操作するときに
スクロールアップ、
スクロールダウンと言っても
非常にわかりにくいので
絶対方向を提供する必要があります
いくつかアクションを追加して
絶対方向でページをめくれるようにします
方向に応じてACTION_PAGE_UPとDOWN
またはLEFTとRIGHTを使用します
先ほどと同様

English: 
and we update the
actions whenever
the relevant state changes.
So now we not only
have logical actions,
but we also have absolute
direction actions.
And we have it for the
horizontal orientation also.
Now, this talk about
logical direction
versus absolute
direction may get
you thinking about another
case, which is right to left UI.
So, over here, Urdu
is being displayed,
which is a language that's
laid out right to left.
And the first page
is on the far right.
So for this, again, we
do something similar.
Based on whether
it's right to left,
we flip action page right
and action page left.
And, again, we go through this
whole cycle of invalidating
the actions, updating state.
And you get it.
So now, regardless
of localization,
our actions are added correctly.
Now, at this point, our
user is able to do--
or our accessibility service
is able to do anything
to this ViewPager that
our user can do to it.
But this ViewPager is also
presenting information.
In this particular
implementation,

Japanese: 
事前にアクションを無効化して
関連する状態が変化するたびに
アクションを更新します
これで論理アクションだけでなく
絶対方向アクションもできました
横方向に関しても同じです
論理方向と絶対方向の話を聞いて
右から左へのUIについて考える方が
いるかもしれません
ここに表示されているウルドゥー語は
右から左へ書く言語です
先頭ページは一番右になります
この場合も同じ作業を行います
言語を書く向きに応じて
ACTION_PAGE_RIGHTとLEFTを切り替えます
やはりアクションの無効化と
状態の更新を実行します
おわかりですね
これでローカライゼーションに関係なく
アクションを正しく追加できます
この時点でユーザー補助サービスは
このViewPagerに対して
ユーザーができることは何でも実行できます
しかしこのViewPagerは
情報も提供しています

Korean: 
액션을 업데이트합니다
관련 상태가 변경될 때마다요
이제 논리적 액션뿐 아니라
절대 방향 액션이 생겼네요
물론 가로 방향에도 똑같이 존재합니다
논리적 방향과 절대 방향에 대해
이야기하다 보면
또 다른 경우를 생각해볼 수 있는데요
바로 방향이 오른쪽에서 왼쪽으로 가는
UI입니다
우르드어는 이렇게 표시됩니다
오른쪽에서 왼쪽으로 쓰는 언어죠
첫 번째 페이지가 가장
오른쪽에 있습니다
여기에서도 비슷한 작업을 합니다
오른쪽이 우선이기 때문에
ACTION_PAGE_RIGHT와
ACTION_PAGE_LEFT를 바꿔줍니다
그리고 액션 무효화와 상태 업데이트
과정을 거칩니다
그럼 완성이죠
현지화 여부에 관계없이
액션이 제대로 추가되었습니다
이제 접근성 서비스는
사용자가 ViewPager에서 할 수 있는
모든 것을 할 수 있습니다
하지만 ViewPager는 정보도 표시합니다
이러한 특정 구현에서는

Indonesian: 
Kita lakukan hal sama.
Kita batalkan tindakan sebelumnya,
Kita perbarui tindakan setiap kali
status yang relevan berubah.
Kita tidak hanya punya
tindakan logis,
tapi juga punya tindakan arah pasti.
Dan juga ada untuk orientasi horizontal.
Bahasan tentang arah logis
vs arah pasti ini
membuat Anda berpikir soal lain,
yaitu UI kanan ke kiri.
Di sini, ada bahasa Urdu
yang ditulis dari kanan ke kiri.
Halaman pertama ada di sebelah kanan.
Jadi kami melakukan hal yang sama
untuk ini.
Berdasarkan apakah
kanan ke kiri,
kita balik halaman tindakan
ke kanan dan kiri.
Sekali lagi, kita lakukan
semua siklus untuk
membatalkan tindakan dan
memperbarui status.
Dan Anda mendapatkannya.
Terlepas dari pelokalan,
tindakan ditambahkan
dengan tepat.
Pada titik ini, pengguna dapat melakukan
atau layanan aksesibilitas kami
dapat melakukan apa pun
ke ViewPager ini yang dapat dilakukan
pengguna kami.
Tapi, ViewPager ini juga
menyajikan informasi.
Pada penerapan ini,

Spanish: 
Primero, invalidamos las acciones
y, luego, las actualizamos
cuando cambia el estado relevante.
Ahora, no solo tenemos acciones lógicas,
sino también de dirección absoluta.
Y también las tenemos
para la orientación horizontal.
Esta charla sobre dirección lógica
vs. dirección absoluta
podría hacerlos pensar en el caso
de izquierda y derecha en la IU.
Aquí, se muestra el idioma urdu,
que se escribe de derecha a izquierda.
La primera página está en el extremo derecho.
En este caso, haremos algo similar.
En función de si es derecha o izquierda,
cambiamos ACTION_PAGE a LEFT o RIGHT.
Luego, nuevamente realizamos
el ciclo de invalidación de acciones
y actualización de estado.
Ahí está.
Sin importar la localización,
nuestras acciones se agregan correctamente.
En este punto, el servicio de accesibilidad
puede realizar en el ViewPager
cualquier acción
que puede realizar el usuario.
Pero ViewPager también presenta información.

Portuguese: 
e atualizamos as ações sempre
que o estado relevante muda.
Agora, temos ações lógicas
e ações de direção absoluta.
E temos isso também para a
orientação horizontal.
A questão de direção lógica
e direção absoluta
pode lembrar outro caso:
IU da direita para a esquerda.
Aqui, vemos o urdu,
que é uma linguagem
da direita para a esquerda.
A primeira página está bem à direita.
Novamente, fazemos algo semelhante:
com base na direção, ativamos
ACTION_PAGE_RIGHT ou ACTION_PAGE_LEFT.
E, mais uma vez, o ciclo de invalidação
das ações e atualização de estados.
E pronto.
Independentemente da localização,
nossas ações são adicionadas corretamente.
Neste ponto, nosso usuário pode...
ou o serviço de acessibilidade
pode fazer tudo
com esse ViewPager que
o usuário possa fazer.
O ViewPager também
apresenta informações.
Nesta implementação específica,

Indonesian: 
berbagai hal ditunjukkan,
seperti jumlah halaman.
Dan hilang ke layanan
aksesibilitas.
Cara kami melakukannya
dengan memisahkan--
membuka API.
Kami juga akan mencampuri
hubungan antara
tampilan dan info node
aksesibilitas.
Kami melakukannya dengan
mengesampingkan info node
aksesibilitas di tampilan.
Dan hal tertentu yang penting adalah
info pengumpulan.
Info pengumpulan adalah objek
di info node aksesibilitas yang membantu
mewakili grup tampilan dengan
sekumpulan tampilan serupa
di bawahnya.
Misalnya, tampilan daftar
punya info koleksi,
RecyclerViews juga punya,
begitu pula
Tab Layouts, dan
ViewPager juga
akan punya info koleksi.
Kami akan membuat jumlah
baris dan kolom,
memasukkannya ke info koleksi.
Kami juga akan mengaitkannya
dengan info node aksesibilitas.
Anda mungkin penasaran
kenapa semua hal ini
kompatibel dengan info node
aksesibilitas,
dan kenapa kami menutup
info node aksesibilitas asli.

Japanese: 
この例では
ページ数などを示しています
この機能が ユーザー補助サービスには
欠けていました
情報の表示を実現するには
APIを利用します
そしてビューとAccessibilityNodeInfoの
関係に手を加えます
ビューのAccessibilityNodeInfoを
初期化の際にオーバーライドするのです
特に注意するのはCollectionInfoです
CollectionInfoは
AccessibilityNodeInfo上のオブジェクトで
下位にある一連の定型ビューで
ビューグループを表せるようにするものです
たとえばリストビューには
CollectionInfoがあります
ある種のRecyclerViewにも
タブレイアウトにもあります
ViewPagerもです
行数と列数を取得して
CollectionInfoに投入して
それをAccessibilityNodeInfoと
関連付けます
このすべてがなぜ
AccessibilityNodeInfoCompatなのか
元のAccessibilityNodeInfoを
なぜラップしているのか
不思議に思うかもしれません

Portuguese: 
ele está indicando algo
como uma contagem de páginas,
que está faltando no
serviço de acessibilidade.
Nós vamos abrir a API.
Vamos mudar a relação
entre a visualização e
AccessibilityNodeInfo.
Fazemos isso modificando
onInitializeAccessibilityNodeInfo
na visualização.
Particularmente, estamos nos
preocupando com collectionInfo.
collectionInfo é um objeto
do AccessibilityNodeInfo que ajuda
a representar grupos de visualização
com um conjunto uniforme de visualizações
abaixo delas.
Por exemplo, uma visualização em lista
tem um collectionInfo,
alguns RecyclerViews têm collectionInfo,
TabLayouts têm e, agora, ViewPager também.
Vamos usar
as contagens de linhas e colunas
em collectionInfo.
Vamos associar isso a
AccessibilityNodeInfo.
Talvez vocês se perguntem
por que tudo aqui é
compatível com AccessibilityNodeInfo e
por que estamos agrupando
o AccessibilityNodeInfo original.

Spanish: 
En esta implementación específica,
se indica el número de página.
Y eso no está
en el servicio de accesibilidad.
Para hacerlo, desglosaremos la API
y manipularemos la relación
entre la vista y la información
del nodo de accesibilidad.
Para ello, anularemos en la vista
onInitializeAccesibilityNodeInfo.
Lo que nos interesa
en particular es collectionInfo.
collectionInfo es un objeto
de AccessibilityNodeInfo
que permite representar grupos de vistas
con un conjunto
de vistas uniformes por debajo.
Por ejemplo, una vista de lista
puede tener un collectionInfo,
así como algunos RecyclerViews
o diseños de pestañas.
Ahora, nuestro ViewPager también tendrá uno.
Tendremos el número de fila y columna;
agréguenlos a collectionInfo.
Y los asociaremos con AccessibilityNodeInfo.
Se preguntarán por qué aquí
aparece tanto AccesibilityNodeInfoCompat
y por qué unimos
el AccesibilityNodeInfo original.

English: 
it's indicating stuff
like a page count.
And that was missing to
the accessibility service.
So the way we're going
to do this is we're
going to break up--
open up the API.
And we're going to mess
with the relationship
between the view and the
accessibility node info.
We do that by overriding on
initialize accessibility node
info on the view.
And the particular thing that we
care about is collection info.
Now, collection
info is an object
on accessibility
node info that helps
represent view groups with
a uniform set of views
below them.
So, for example, a list
view has a collection info--
certain RecyclerViews
have collection infos,
Tab Layouts do, and
now our ViewPager
is going to have that, too.
We're going to get the
row count, column count,
throw that into the
collection info.
And we're going to associate
that with the accessibility
node info.
Now, you may be wondering
why everything over here
is accessibility
node info compat,
and why we're wrapping
the original accessibility
node info.

Korean: 
페이지 수와 같은 것을 의미합니다
접근성 서비스에는 빠져 있던 거죠
그렇기 때문에
여기에서 하려는 일은
API를 여는 것입니다
뷰와 접근성 노드 정보의 관계를
흐트러뜨리는 거죠
뷰에서 onInitializeAccessibilityNodeInfo
를 재정의하여
흐트러뜨리는 거예요
저희가 특별히 신경 쓰는 것은 collection info입니다
collection info는
접근성 노드 정보상의 객체로
하위 뷰의 동일한 세트가 있는 뷰 그룹이
표시되도록 합니다
예를 들어 목록 뷰에는
collectionInfo가 있고
특정 RecyclerView에
collectionInfo가 있으며
'탭 레이아웃'과 새로운 ViewPager에도
collectionInfo가 있습니다
rowCount와 columnCount도
collectionInfo에 넣습니다
그리고 접근성 노드 정보에
결합합니다
여기에서 아마 왜 모든 것이
AccessibilityNodeInfoCompat인지
기존 접근성 노드 정보를
왜 래핑하는지 궁금하실 겁니다

Indonesian: 
Info node aksesibilitas adalah
objek di platform.
Kompatibilitas info node aksesibilitas
adalah objek di AndroidX.
Kami menutup, kami meminta
developer aplikasi menutup
info node di kompatibilitas info node,
karena memungkinkan kami
mengembalikan API ke API 19,
dan memungkinkan kami
mengembalikan perbaikan bug
tertentu ke API 19.
Secara umum, ini praktik baik,
meskipun tidak menggunakan
API baru yang
tidak bisa digunakan di perangkat lama.
Memang bagus.
Kami, sebagian besar, mewakili
ViewPager kami dengan cukup baik
untuk layanan aksesibilitas.
Tapi, dengan sedikit pengujian,
kami menemukan jumlah halaman
mulai tidak digunakan.
Untuk memahami asal bug ini,
Anda harus paham
cara kerja ViewPager.
Lihat, ViewPager tidak mengelola
itemnya sendiri.
Malah SubView dari RecyclerView
yang mengelola itemnya.
Kapan pun ada perubahan di ViewPager,
RecyclerView mengirimkan
peristiwa aksesibilitas.
Saat menerima peristiwa itu,
layanan aksesibilitas
membatalkan bagian hierarki

Portuguese: 
AccessibilityNodeInfo é um
objeto da plataforma.
AccessibilityNodeInfoCompat
é um objeto no AndroidX.
Nós pedimos que os
desenvolvedores de app unissem
NodeInfos em NodeInfoCompats
porque isso permite oferecer
retrocompatibilidade com a API 19
e com correções de bugs dessa versão.
De um modo geral, isso é recomendado,
mesmo que você não use
uma nova API que não
pode usar em um dispositivo mais antigo.
Isso é ótimo.
De modo geral,
representamos ViewPager
muito bem no serviço de acessibilidade.
Mas, com alguns testes,
descobrimos que essa contagem
de páginas começa a ficar desatualizada.
Para entender onde começa esse bug,
temos que entender como o
ViewPager realmente funciona.
O ViewPager não gerencia
os próprios itens sozinho.
Quem faz isso
é o SubView ou o RecyclerView.
Sempre que há uma
mudança no ViewPager,
o RecycleView envia
eventos de acessibilidade.
Quando o serviço de
acessibilidade recebe os eventos,
ele invalida parte da hierarquia

Korean: 
접근성 노드 정보 자체는 플랫폼에 있는 객체이고
AccessibilityNodeInfoCompat는
AndroidX에 있는 객체입니다
저희는 앱 개발자분들께 노드 정보를
NodeInfoCompat에 래핑하실 것을
권하는데
이렇게 해야 API를 API 19로
백포팅할 수 있으며
특정 버그 수정 사항을 API 19로
다시 백포팅할 수 있습니다
일반적인 권장사항일 뿐입니다
기존 기기에서 사용할 수 없는
새로운 API를
활용하지 않는 경우에도 말이죠
네, 좋습니다
지금까지 ViewPager를
접근성 서비스에 잘 표시했습니다
테스트하는 동안
페이지 수가 업데이트되지
않고 있다는 걸 확인했어요
이 버그의 원인을 파악하려면
ViewPager의 실제 작동 방법을
이해해야 하죠
ViewPager는 스스로 항목을 관리하지 않습니다
항목을 스스로 관리하는
RecyclerView의 SubView와 다르죠
ViewPager에 변경이 있을 때마다
RecyclerView는 접근성 이벤트를
전송합니다
접근성 서비스에서 해당 이벤트를
수신하면
계층 구조의 일부를 무효화하고

Spanish: 
AccessibilityNodeInfo
es un objeto de la plataforma.
AccessibilityNodeInfoCompat
es un objeto de AndroidX.
Les pedimos a los desarrolladores de apps
que unan sus NodeInfo en NodeInforCompat
porque así podemos
realizar un backport de la API
y de las correcciones de errores a la API 19.
En general, esta es una práctica recomendada
incluso si no usan una API nueva
que no pueda usarse en dispositivos antiguos.
Muy bien.
Presentamos correctamente nuestro ViewPager
al servicio de accesibilidad.
Pero si hacemos pruebas,
veremos que el contador de páginas
se vuelve inactivo.
Para encontrar el origen del error,
debemos comprender cómo funciona ViewPager.
ViewPager no administra sus elementos.
En su lugar, es el SubView del RecyclerView
el que los administra.
Cuando ocurre un cambio en ViewPager,
RecyclerView envía
los eventos de accesibilidad.
Cuando el servicio de accesibilidad
recibe los eventos,

Japanese: 
AccessibilityNodeInfo自体は
プラットフォームのオブジェクトです
AccessibilityNodeInfoCompatは
AndroidXのオブジェクトです
私たちは NodeInfoをNodeInfoCompat内に
ラップするよう 開発者に要求しました
そうすれば APIをAPI 19に または
特定のバグフィックスをAPI 19に
バックポートできるからです
古いデバイスでは使用できない新しいAPIを
利用していない場合でも この方法は役立ちます
ViewPagerはユーザー補助サービスに
かなりうまく表現されますが
少しテストしてみると
ページ数の情報が古くなることがわかりました
このバグの原因を理解するには
実際の動作を
ある程度理解する必要があります
ViewPager自体はアイテムを管理しません
RecyclerViewのサブビューが
アイテムを管理します
ViewPagerに変更が発生するたびに
RecyclerViewが
AccessibilityEventを送信します
ユーザー補助サービスが
イベントを受信すると

English: 
Accessibility node info itself
is an object in the platform.
Accessibility node info compat
is an object in AndroidX.
Now, we wrap-- we ask
app developers to wrap
their node infos in
node info compats,
because that allows us to
backport API back to API 19,
and also allows us to backport
certain bug fixes back
to API 19.
So, in general, this
is just good practice,
even if you're not
utilizing a new API that you
can't use on an older device.
OK, so that's great.
We're, for the most part,
representing our ViewPager
pretty well to the
accessibility service.
But with a little
bit of testing,
we find that that page
count starts to go stale.
And to understand where
this bug came from,
you kind of have to understand
how ViewPager really works.
See, ViewPager doesn't
manage its items itself.
And instead of the
SubView of a RecyclerView,
which manages its items.
And whenever a change
happens to the ViewPager,
the RecyclerView sends
the accessibility events.
When the accessibility
service receives those events,
it invalidates that
part of the hierarchy

Japanese: 
変更部分を階層内で無効にして
再度クエリします
ViewPagerには再度クエリが
行われませんでした
ページ数を表していた列数を含め
ViewPagerに関連付けられた情報は
すべて古くなっています
ここでの対策は 変更に関する
AccessibilityEventを
RecyclerViewからではなく
ViewPagerから送信することです
これで ViewPagerによって
ユーザー補助サービスは ユーザー同様の
操作を実現できるだけでなく
ユーザーに提供されるすべての情報を
得られるようになります
ユーザー補助フレームワークも
一役買っています
RecyclerViewで使用されるコードに基づいて
現在のインデックスをすでに実行していたのです
RecyclerViewを使用したのは
おそらく正解でした
ただし お気づきかもしれませんが
ユーザー補助についての
詳しい知識がなければ
このような解決策の多くは
やや複雑でわかりにくいものです
実際 必要以上に紛らわしい名前もあります

Indonesian: 
dan meng-kueri ulang ViewPager.
Lihat cara ViewPager tidak di-kueri lagi.
Jadi, semua info terkait
tidak digunakan,
termasuk jumlah kolom yang muncul
pada jumlah halaman.
Yang bisa dilakukan
di situasi ini,
kita pastikan peristiwa aksesibilitas
untuk perubahan yang penting
dikirim dari ViewPager,
bukan RecyclerView.
Kini, ViewPager tidak hanya
memungkinkan layanan aksesibilitas
bertindak dengan cara yang
disukai pengguna,
tapi menyajikan semua informasi
ke layanan aksesibilitas
yang disajikan ke pengguna.
Dan beberapa dilakukan melalui
framework aksesibilitas.
Saya sebutkan indeks saat ini.
Yang dikerjakan di
framework aksesibilitas,
menurut kode yang dipakai
di RecyclerView.
Mungkin itu alasan
Jel dan Jacob
menggunakan RecyclerView di sini.
Sepertinya bagus.
Pasti kalian memperhatikan
banyak perbaikan yang dilibatkan
sedikit lebih rumit
dan sulit ditemukan,
jika Anda tak punya pengetahuan mendalam
tentang aksesibilitas.
Nyatanya, beberapa hal ini
tidak sejelas seperti yang Anda pikirkan.

Portuguese: 
e a consulta novamente.
O ViewPager
nunca foi consultado de novo.
Todas as informações
associadas a ele
estão desatualizadas, incluindo
a contagem de colunas que
revelava a contagem de páginas.
O que podemos fazer
é garantir que os eventos
de mudanças importantes para nós
sejam enviados do ViewPager
e não do RecyclerView.
Agora, o ViewPager não apenas
permite que o serviço de acessibilidade
aja nele de todos os modos possíveis,
mas está apresentando 
as mesmas informações
ao serviço de acessibilidade
e ao usuário.
Parte disso se deu por meio
do framework de acessibilidade.
Eu mencionei o índice atual.
Isso já foi feito com
o framework,
com base no código do RecyclerView.
Foi uma boa ideia de Jel e Jacob
usar o RecyclerView aqui.
Parece ótimo, mas vocês podem
ter notado que várias dessas
correções envolvidas são
um pouco mais complicadas
e mais difíceis de encontrar
se vocês não têm um bom conhecimento
sobre acessibilidade.
De fato, alguns desses itens
não são tão simples
quanto vocês imaginam.

Spanish: 
invalida esa parte de la jerarquía
y vuelve a solicitarla.
Noten que no volvió a solicitarse ViewPager.
Ahora, toda la información
asociada a él está inactiva,
incluido el número de columna
que indicaba el número de página.
En esta situación, debemos asegurarnos
de que los eventos de accesibilidad
relacionados con los cambios importantes
se envíen desde ViewPager,
y no desde RecyclerView.
Ahora, ViewPager no solo permite
que el servicio de accesibilidad
actúe tal como lo hace el usuario,
sino que también
le presenta toda la información
que le muestra al usuario.
Parte se hizo
con el marco de trabajo de accesibilidad.
Mencioné el índice actual
que ya se había hecho con ese marco
según el código que se usó en RecyclerView.
Fue buena idea decirles a Jel y Jacob
que usaran RecyclerView en este caso.
Pero habrán notado
que varias de estas correcciones
eran más complejas y difíciles de encontrar
si no tienen muchos
conocimientos sobre accesibilidad.
De hecho, algunas de estas correcciones
no son tan directas como parecen.

Korean: 
이에 대해 쿼리를 재실행합니다
ViewPager는 쿼리 재실행의 대상이
아니었죠
따라서 이와 관련된 정보는 최신 정보가 아닙니다
페이지 수를 표시하는 columnCount도
마찬가지입니다
이러한 상황에서 할 수 있는 것은
변경사항에 대한 접근성 이벤트를
확인하는 것입니다
RecyclerView가 아닌
ViewPager에서 전송되었음을 말이죠
이제 ViewPager를 통해 접근성 서비스는
사용자가 할 수 있는 모든 방식으로
액션을 취하고
사용자에게 표시되는 모든 정보를
접근성 서비스에 표시합니다
이 중 일부는 접근성 프레임워크에 의해
완료됩니다
현재 인덱스에 대해
언급했었는데요
이미 접근성 프레임워크를 통해
완료됐습니다
RecyclerView에서 사용되는
코드를 기반으로 말이에요
젤과 제이컵이 여기에서 RecyclerView를 사용한 데는
다 이유가 있는 거죠
그런데 여기에서
관련된 많은 수정사항이
더 복잡하거나 이해하기
어렵다고 느끼실 수 있습니다
접근성에 대한 충분한 이해가
없으시다면 말이죠
생각보다
간단하지 않게 느끼실 수 있습니다

English: 
and re-queries for it.
Notice how that ViewPager
was never queried for again.
So now all of the information
associated with it
is stale, including
that column count that
was surfacing the page count.
So what we can do
in this situation
is we made sure that
the accessibility events
for the changes
that we cared about
were sent from the ViewPager,
instead of the RecyclerView.
Now our ViewPager not only
allows accessibility service
to act on it in every
way that a user can,
but it's presenting
all of the information
to the accessibility service
that it presents to the user.
And some of that
was done through
the accessibility framework.
I mentioned the current index.
That was already done through
the accessibility framework,
based on code that was
used in RecyclerView.
So that was probably a
good call by Jel and Jacob
to use RecyclerView here.
But it sounds
great, but you guys
may have noticed that a
lot of these fixes involved
were a little bit more
complicated and a little bit
harder to come
across, if you don't
have an intimate knowledge
of accessibility.
And, in fact, some
of these things,
they don't seem as
straightforward as you think.

Portuguese: 
Por exemplo, rolar para frente
e página para a direita.
Por que não é página para frente
ou rolar para a direita?
Por que não podemos fazer
algo que pareça um pouco
mais consistente?
Parte vem do fato
de que isso é um código legado.
Trabalhamos com serviços
antigos que precisam de compatibilidade.
Parte é porque
essa API é muito complicada.
Devido a todos os detalhes, idade,
complexidade e APIs de
acessibilidade de níveis inferiores,
quanto mais trabalha, mais difícil
sua vida se torna.
Mais você precisará
entender a acessibilidade, 
além daquilo
que a documentação apresenta.
Vejam neste gráfico.
É a nossa observação de quanto trabalho
de acessibilidade
vocês precisam fazer, com base
na forma como sua IU está personalizada.
Há outras observações de dentro do Google.
O mais fácil... o que esperamos
que todos façam, mas que não é possível...
é que vocês usem todos os widgets padrão
que oferecemos nos frameworks.
Eles têm acessibilidade
incorporada.
Vocês só precisam rotular suas imagens,
isso é rápido.

English: 
Like, for example, you look
at accessibility scroll
forward and
accessibility page right.
Why isn't it page forward?
Or why isn't it scroll right?
Why can't we do
something that seems
a little bit more consistent?
And some of this has
to do with the fact
that this is Legacy
Code and we're
working with certain older
accessibility services that
need to be supported, right?
Some of it has to
do with the fact
that this API is
pretty complicated.
So because of all of
this nuance, and age,
and complexity, and the lower
level accessibility APIs,
the more you try to work
here, the more difficult
your life is going to be.
The more you're
going to really need
to understand accessibility,
even beyond what
the documentation presents.
This is captured in
this chart over here.
This is our observation
of how much accessibility
work you're going to need to do,
based on how custom your UI is.
These are our observations
from inside Google.
So at the easiest end-- what we
hope everyone does, but really,
realistically, is not possible--
is that you use all
the standard widgets
we provide to you
in our frameworks.
These come with accessibility
built in out of the box,
and all you have to do
is label your images,
which shouldn't
take long at all.

Spanish: 
Por ejemplo, ACCESSIBILITY_SCROLL_FORWARD
y ACCCESSIBILITY_PAGE_RIGHT
¿por qué no son PAGE_FORWARD ni SCROLL_RIGHT?
¿Por qué no podemos
crear algo más consistente?
En parte, se debe a que es código heredado
y a que trabajamos
con servicios de accesibilidad antiguos
que deben ser compatibles.
Por otro lado, esta API es bastante compleja.
Entonces, debido
a la antigüedad y complejidad,
y a las API específicas de accesibilidad,
trabajar en este sistema
les resultará muy complicado
y necesitarán más que nunca
comprender la accesibilidad más allá
de lo que presenta la documentación.
Pueden ver todo en este gráfico.
Esta es la estimación del trabajo
de accesibilidad que deberán hacer
en función del nivel
de personalización de su IU.
Estas observaciones son internas de Google.
La forma más fácil,
que esperamos que todos implementen,
pero que es en realidad imposible,
es usar todos los widgets estándares
que ofrecemos en nuestros marcos de trabajo.
Estos incluyen accesibilidad integrada
y solo tienen que etiquetar las imágenes,
que no debería llevarles mucho tiempo.

Indonesian: 
Misalnya, Anda lihat
scroll aksesibilitas maju
dan halaman aksesibilitas kanan.
Kenapa bukan halaman maju?
atau bukan scroll kanan?
Kenapa kami tidak bisa melakukan
sesuatu yang sedikit lebih konsisten?
Sebagian ada hubungannya
dengan Kode yang Lawas ini,
dan kami bekerja dengan layanan
aksesibilitas yang lebih lama
yang perlu didukung, kan?
Sebagiannya disebabkan
oleh cukup rumitnya API ini.
Karena semua nuansa ini,
usia, kerumitan,
dan API aksesibilitas tingkat
lebih rendah,
semakin mencoba bekerja
di sini,
semakin sulit pula hidup Anda.
Semakin Anda perlu paham aksesibilitas,
bahkan melebihi yang ada
di dokumentasi.
Ada dalam diagram ini di sini.
Ini pengamatan kami,
seberapa banyak pekerjaan
aksesibilitas yang perlu dilakukan,
berdasarkan seberapa kustomnya UI Anda.
Ini pengamatan kami dari
dalam Google.
Kesimpulannya,
kami ingin semua orang,
meskipun tidak mungkin,
menggunakan semua widget standar
yang kami berikan
di framework.
Dengan aksesibilitas
siap pakai,
dan Anda hanya perlu
melabeli gambar,
yang tidak butuh waktu lama.

Korean: 
예를 들어 accessibility scroll forward와
accessibility page right 말이죠
왜 page forward가 아닌지
혹은 scroll right이 아닌지
좀 더 일관성 있게
할 수는 없는지 하고 궁금해하실 수
있습니다
이러한 내용 중 일부는
이것이 레거시 코드라는 점
그리고 저희가 지원이 필요한
이전의 특정 접근성 서비스로 작업하고
있다는 점과 관련이 있습니다
이 API가 꽤 복잡하다는 점도
이와 관련이 있습니다
미묘한 차이, 시기,
복잡성, 하위 수준의 접근성 API 때문에
작업을 하면 할수록
더 힘들어지게 됩니다
접근성을 이해할 필요가 더 커지게 되죠
문서를 통해 알 수 있는 것
이상으로 말이에요
여기 보시는 것은 차트에서
캡처한 부분입니다
UI 맞춤설정의 정도에 따라
접근성 작업이 얼마나 필요한지를
관찰한 것입니다
Google 내에서 관찰한 결과입니다
현실적으로 가능성이
크지는 않지만
표준 위젯을 사용하시길 바라고 있어요
저희가 프레임워크에서 제공하는
위젯 말이죠
바로 활용할 수 있도록
빌드된 접근성을 통해 제공되며
이미지 라벨을 지정하기만 하면 되는데
이조차도 금방 끝납니다

Japanese: 
たとえばACTION_SCROLL_FORWARDと
ACTION_PAGE_RIGHTは
なぜPAGE_FORWARDと
SCROLL_RIGHTではないのか？
なぜもっと一貫性を持たせることが
できないのか？などです
その理由は
これがレガシーコードであること
古いユーザー補助サービスを
使用していること
そしてAPIがかなり複雑であることに
関係があります
このように微妙な違いや古さ、複雑さや
低水準のユーザー補助APIにより
作業しようとすればするほど
困難になります
マニュアルに書かれている以上の
理解が必要になります
この図のとおりです
これはUIのカスタムの程度に応じて
必要になる
ユーザー補助関連の作業の量を示しています
Google内部から得られた分析情報です
非現実的ですが
最も簡単で理想的な方法は
ユーザー補助フレームワークで提供される
標準ウィジェットのみを使用することです
初めから機能が備わっているので
画像のラベル付けさえすればよく
時間はかかりません

Portuguese: 
Depois de usar novos widgets,
as coisas começam a ficar menos simples,
como vimos com o ViewPager,
um widget razoavelmente bem
construído, que usa outros widgets padrão.
Mas as coisas eram
um tanto complicadas.
Se for preciso
criar ferramentas de IU
ou uma nova plataforma,
vai ser muito complicado.
Vários engenheiros
deverão trabalhar integralmente
com isso para
garantir que não afetem seus usuários.
Movam o máximo possível
para a esquerda do gráfico.
Se realmente precisarem ir
para a direita do gráfico,
analisem detalhadamente quanto
trabalho será necessário e
aloquem recursos.
Caso contrário, vocês estarão
prejudicando os usuários nesse sentido.
A última coisa que eu
gostaria de abordar
é bastante importante: os testes.
Surpreendentemente, é fácil
encontrar bugs de acessibilidade,
principalmente porque
não é um caso de uso
ou um código exercitado com frequência.
Há maneiras óbvias de executar testes.

English: 
Now, once you move into
a new widget territory,
you can see this is where things
start getting more non-trivial,
like we just saw
with ViewPager, which
was a reasonably well-built
widget which utilized
some other standard widgets.
But things were
kind of complicated.
And if you have to
start building a new UI
toolkit, or a new
UI platform, it's
going to be very,
very complicated.
You're going to need multiple
engineers working full time
on accessibility to
make sure you don't
hurt your accessibility users.
So what we encourage you to do
is move to far, to the left,
of this chart as possible.
And if you really have to be on
the right side of this chart,
then make sure you are
honest about how much
work it's going to take, and
you allocate those resources.
Because, if you
don't, you're choosing
to hurt your users in this way.
Now, the last bit that
I want to touch upon,
which is kind of
important, is testing.
It's surprisingly easy to
ship bugs with accessibility,
especially because accessibility
is not a used case or code
part that's exercised often.
So there's a couple
obvious ways of testing.

Korean: 
이제 새로운 위젯의 영역에서
더 중요한 작업이 가능하다는 것을
확인하실 수 있을 겁니다
기타 표준 위젯을 활용한
비교적 잘 빌드된
ViewPager에서 확인하신 것처럼 말이죠
하지만 복잡해진 부분이 있습니다
새로운 UI 툴킷이나 UI 플랫폼을
빌드해야 하는 경우라면
더 복잡해집니다
접근성 사용자에게
불편함을 주지 않도록
접근성 작업을 맡을 상근 엔지니어가
여러 명 필요하게 됩니다
그렇기 때문에 이 차트에서
최대한 왼쪽으로 움직이시기를 바랍니다
차트의 오른쪽에 해당할 수밖에 없다면
작업이 얼마나 걸릴지 냉철하게
판단하시고
리소스를 할당하시기 바랍니다
그렇지 않으면 사용자에게
불편함을 줄 수밖에 없습니다
자 이제 마지막 내용은
꽤 중요한 내용인 테스트하기입니다
접근성을 통해 버그를 보내기는
매우 쉽습니다
접근성은 사용된 사례 또는
자주 실행되는 코드 부분이 아니기
때문입니다
명확하게 테스트하는 방법이 두 가지가 있습니다

Japanese: 
新しいウィジェットを作成しようとすると
そうはいきません
先に見た ViewPagerは
他の標準ウィジェットを利用して
かなりうまく作られているウィジェットですが
話はやや複雑になりました
新しいUIツールキットやUIプラットフォームを
作成するとなると 非常に複雑になります
ユーザーを困らせないためには
複数のエンジニアがフルタイムで
関連作業を行う必要があります
ですから この図の左端を
目指すことをおすすめします
右側にあるものがどうしても必要な場合は
発生する作業量を正直に伝え
リソースを割り当ててください
そうしなければ
ユーザーが困ることになるからです
最後にお話ししたい
重要なポイントはテストです
ユーザー補助機能は
バグを残したままリリースされやすいものです
よく使われるユースケースや
コードではないからです
わかりやすいテスト方法は２つ

Indonesian: 
Setelah menggunakan widget baru,
di sinilah segalanya menjadi lebih rumit,
seperti di ViewPager tadi,
widget yang dibuat dengan sangat baik
yang menggunakan widget standar lainnya.
Tapi, semua jadi rumit.
Jika Anda harus mulai
membuat toolkit
atau platform UI baru,
akan jadi sangat rumit.
Dibutuhkan banyak engineer
yang bekerja penuh waktu
pada aksesibilitas untuk
memastikan Anda tidak
merugikan pengguna aksesibilitas Anda.
Saran kami, bergeraklah ke kiri
diagram ini sejauh mungkin.
Jika Anda harus ada
di sisi kanan diagram,
pastikan Anda benar-benar
menyatakan durasi pekerjaan,
dan Anda mengalokasikan
resource tersebut.
Jika tidak, Anda akan merugikan
pengguna Anda.
Hal terakhir
yang ingin saya sampaikan,
yang sangat penting,
yaitu pengujian.
Sangat mudah untuk mengirimkan
bug dengan aksesibilitas,
terutama karena aksesibilitas
bukan bagian kode atau
kasus yang sering digunakan.
Jadi ada beberapa cara
pengujian yang jelas.

Spanish: 
Al comenzar a usar otros widgets,
pueden ver
que las cosas dejan de ser triviales,
como vimos con ViewPager,
que es un widget razonablemente bueno,
que a su vez usa otros widgets estándares.
Pero los procesos eran complicados.
Y si deben crear
un nuevo kit de herramientas de IU
o una nueva plataforma de IU, será
aún más complicado.
Deberán tener varios ingenieros
trabajando tiempo completo
en accesibilidad para asegurarse
de no perjudicar a esos usuarios.
Por eso, les recomendamos
mantenerse lo más a la izquierda
que puedan dentro de este gráfico.
Y, si realmente
quieren quedarse a la derecha,
asegúrense de ser honestos
sobre cuánto trabajo les llevará
y asignar los recursos correspondientes.
Porque si no lo hacen,
perjudicarán a los usuarios.
El último concepto que quiero abordar,
que es bastante importante, son las pruebas.
Es muy fácil
publicar errores en accesibilidad,
sobre todo porque no es un caso práctico
ni un fragmento de código
que se use con frecuencia.
Estas son dos formas obvias 
para hacer pruebas.

Korean: 
첫 번째는 접근성 서비스를 직접
개시하는 것입니다
음성 안내 지원, 스위치 제어를
실행하고 작동 방법을 확인하세요
코드를 작성할 때는 중요해보이지
않지만
사용자에게는 큰 불편함을
초래할 수 있는
미묘한 버그를 파악하는 데
좋은 방법입니다
다른 방법은 유닛 테스트 또는
자동 테스트입니다
두 가지 방식이 있습니다
하나는 뷰에서 액션을 실행하고
뷰의 상태를 확인하는 것이고
다른 하나는 뷰에 상태를 만들어
이 뷰를 기반으로 접근성 노드 정보를
생성하고
노드 정보 상태가 뷰를 제대로
반영하는지
확인하는 것입니다
기억하셔야 할 중요한 내용이
두 가지 있는데요
다른 부분에서 집중하지 못하셨더라도
이 두 가지는 꼭 기억하시기 바랍니다
첫 번째는 사용자에게 표현되는
모든 것을
접근성 서비스에 표현해야 한다는
것입니다
그렇지 않으면
접근성 사용자의 UI 활용이나
UI를 통한 활동을 제대로
지원하지 못하게 됩니다

Spanish: 
La primera es abrir
los servicios de accesibilidad por su cuenta,
ejecutar TalkBack y accesibilidad mejorada,
y ver cómo funcionan.
En general, esta es una buena forma
de encontrar esos errores sutiles
que no parecen graves
cuando escriben el código,
pero que pueden
frustrar mucho a los usuarios.
La otra forma es probar
la unidad o la automatización.
Se puede realizar de dos maneras.
Una es realizar una acción en una vista
y revisar el estado en esa vista.
La otra es crear un estado en una vista
y, luego, crear un AccessibilityNodeInfo
basado en esa vista
y verificar que el nodo
refleje esa vista correctamente.
Los dos conceptos principales
que no deben olvidar
aunque no hayan prestado atención hoy,
son, en primer lugar,
que todo lo que expresen al usuario
deben expresarlo
al servicio de accesibilidad.
Si no lo hacen, significa que no quieren
que el usuario de accesibilidad
use la IU ni actúe en su IU de esa forma.

Portuguese: 
A primeira é você mesmo
abrir os serviços de acessibilidade.
Vejam como funcionam o TalkBack
e o acesso com interruptor.
Normalmente, essa é uma boa maneira
de encontrar bugs sutis
que não parecem significativos
ao criar o código,
mas que depois se tornam
frustrantes para os usuários.
A outra maneira são os testes
de unidades ou automação.
Eles assumem duas formas.
Uma é executar uma ação
em uma visualização
e verificar o estado nela.
A outra é criar um estado
na visualização e um AccessibilityNodeInfo
com base na visualização.
Depois, ver se o estado de NodeInfo
reflete a visualização corretamente.
Há duas grandes conclusões aqui.
Mesmo que não tenham
prestado atenção nas outras partes,
as duas coisas que vocês não
podem esquecer são:
primeiro,
tudo o que você expressa ao usuário,
tem que expressar ao
serviço de acessibilidade.
Caso contrário, você está dizendo
que não quer que o
usuário de acessibilidade
consuma essa IU ou aja na
sua IU dessa forma.

Japanese: 
１つは 自分で使ってみることです
TalkBackやスイッチアクセスを実行して
動作を確認します
コード作成時には それほど重要に思えないが
ユーザーをとても苛立たせることになる
小さなバグが見つけられます
もう１つは単体テストまたは自動テストで
通常２つの形態をとります
１つはビューに対してアクションを実行し
ビューの状態を確認するという形です
もう１つは
ビューに何らかの状態を作成してから
そのビューの
AccessibilityNodeInfoを作成し
AccessibilityNodeInfoの状態が
ビューを正しく反映していることを
確認するという形です
次の２点は非常に重要なポイントです
他の話をしっかり聞いていなくても
この２点は忘れないでください
まずユーザーに示すすべての情報を
ユーザー補助サービスに示してください
そうしないと
補助を必要とするユーザーに
そのUIを使わせたくないと
言っていることになります
２点目です

Indonesian: 
Pertama, buka sendiri layanan
aksesibilitas.
Jalankan TalkBack dan Switch Access,
lalu lihat cara kerjanya.
Biasanya, ini cara yang baik untuk
mencari bug yang tidak kentara
yang tidak begitu berarti
saat Anda menulis kode,
tetapi membuat pengguna
sangat frustrasi.
Lainnya, pengujian unit atau
pengujian otomatisasi.
Biasanya dalam dua bentuk.
Pertama, Anda melakukan
tindakan di tampilan,
lalu memeriksa status
di tampilan.
Yang kedua, Anda membuat
beberapa status di tampilan,
lalu membuat info node aksesibilitas,
berdasarkan tampilan,
lalu memeriksa
apakah status info node
mencerminkan tampilan dengan tepat.
Dua bagian utama
yang perlu diperhatikan,
jika Anda tidak memperhatikan
bagian lainnya,
dua hal yang harus Anda ingat,
pertama,
semua yang Anda ungkapkan
ke pengguna,
harus diungkapkan ke layanan
aksesibilitas.
Jika tidak, berarti Anda tidak ingin
pengguna aksesibilitas menggunakan
UI tersebut atau bertindak di UI Anda
dengan cara tersebut.

English: 
The first is just open up
the accessibility services
yourself.
Run TalkBack, run Switch
Access, see how it works.
Typically, this is a good way of
finding those very subtle bugs
that don't seem that significant
when you're writing code,
but turn out to be very
frustrating for users.
The other is unit testing
or automation testing.
These take typically two forms.
One is you perform
an action on a view,
and you check the
state on the view.
And the other is you create
some state on a view,
and you create an accessibility
node info, based on that view,
and you check to see that
the node info state reflects
that view correctly.
So the two really big
key takeaways here--
if you guys didn't pay attention
to any other part of this,
the two things that you can't
forget about are, first,
everything that you
express to your user,
you have to express to
the accessibility service.
If you don't, then
what you're saying
is you don't want the
accessibility user
to be able to consume that UI
or act on your UI in that way.

Korean: 
두 번째는 접근성 작업이
맞춤설정 UI 양에 비례해
대폭 늘어난다는 것입니다
따라서 표준 위젯을 최대한 많이
활용하고
맞춤설정 UI 사용을 최대한 피하면
가치에 온전히 집중할 수 있게 되죠
애플리케이션이나 UI가
이 세계에 제공하는 가치 말이에요
자체 UI나 맞춤 위젯을 반드시
작성해야 하는
근거가 분명한 경우
접근성 작업이 얼마나 걸릴지
정확히 계산하시고
범위를 미리 파악하셔서
리소스를 할당하세요
그렇지 않으면
제품을 발송해야 하는데
액세스할 수 없는 제품밖에 없어서
사용자에게 불편함을 끼치게 됩니다
강연에 참석해주셔서 감사합니다
감사합니다
[음악 재생]

Spanish: 
El segundo es que el trabajo de accesibilidad
aumenta de manera proporcional
a la personalización de su IU.
Por ello, usen la mayor cantidad
de widgets estándares que puedan.
Eviten lo más posible la IU personalizada
para poder concentrarse en el valor
que su aplicación o IU ofrece al mundo.
Y, si realmente quieren escribir su propia IU
o widgets personalizados,
porque hay situaciones que lo ameritan,
sean honestos con la cantidad de trabajo
de accesibilidad que se requerirá,
mídanlo con anticipación
y dedíquenle los recursos necesarios.
De lo contrario, podría pasar que, 
cuando estén por publicar,
noten que su producto es inaccesible
y que no solo se verá terrible,
sino que también
perjudicará mucho a sus usuarios.
Gracias por su tiempo y por venir.

Indonesian: 
Yang kedua, pekerjaan
aksesibilitas Anda diskalakan
secara dramatis dengan jumlah
UI kustom yang dimiliki.
Gunakan widget standar
sebanyak mungkin.
Jangan gunakan UI kustom
sebanyak mungkin,
jadi Anda bisa berfokus
pada nilai
yang diberikan aplikasi atau UI
kepada dunia.
Jika benar-benar harus menulis
UI sendiri,
karena ada situasi
yang dijamin untuk itu,
atau widget kustom Anda sendiri,
sampaikan dengan jujur
durasi pekerjaan aksesibilitas
dan periksa di awal,
dan dedikasikan resource tersebut.
Jika tidak, Anda akan terjebak
di situasi
bahwa Anda akan mengirim,
dan ada produk
yang tidak dapat diakses,
ini terlihat cukup mengerikan,
dan pengguna akan sangat terluka.
Bagaimana pun juga,
terima kasih sudah hadir.
Saya sangat menghargainya.
[MUSIK DIPUTAR]

English: 
And the second is your
accessibility work scales
dramatically with the amount
of custom UI you have.
So, again, try to use standard
widgets as much as possible.
Try to avoid using custom
UI as much as possible,
so you can really
focus on the value
that your application or your
UI delivers to the world.
And if you really have
to write your own UI,
because there are warranted
situations for that--
or your own custom widgets--
then just be very honest
about how much accessibility
work it's going to take,
and scope it in advance,
and dedicate those resources.
Otherwise, you're going to
catch yourself in a situation
where you're about to ship,
and you have an inaccessible
product, and it's going
to look pretty awful,
and you're going to hurt
you users pretty badly.
Either way, thank you
guys for your time.
I really appreciate it.
[MUSIC PLAYING]

Portuguese: 
A segunda é: seu trabalho de
acessibilidade aumenta muito
de acordo
com o volume de IU personalizada.
Novamente, tente usar widgets
padrão o máximo possível.
Tente evitar usar IU personalizada
o máximo possível
para que possa
se concentrar no valor
que seu app ou sua IU
oferece ao mundo.
Se realmente tiver
que criar sua própria IU,
seja porque há situações legítimas
ou widgets personalizados...
seja honesto sobre quanto trabalho
de acessibilidade será necessário,
planeje-se e aloque recursos.
Caso contrário, você vai se
ver em uma situação
em que poderá ter um
produto inacessível,
o que pode ser bastante ruim
e afetará seus usuários negativamente.
Obrigado pela atenção.

Japanese: 
独自UIが増えるほど
ユーザー補助関連の作業量も劇的に増えます
なるべく
標準ウィジェットを使用してください
できるかぎり独自UIを
使用しないようにすれば
アプリやUIがもたらす
価値に集中できます
正当な事情があってどうしても独自UIや
カスタムウィジェットを
作成しなければならない場合は
必要な関連作業の量を正直に伝え
事前に範囲を定義して
リソースを投入してください
そうしないと リリース寸前になって
ユーザー補助機能のない製品だと
気づくことになり
ユーザーをひどく困らせる
大変な結果になってしまいます
ご静聴ありがとうございました
